finaX

finaX is an e-invoicing API for XRechnung, ZUGFeRD, Factur-X, and EN 16931 documents. Agents convert between JSON invoice models, CII or UBL XML, and ZUGFeRD PDFs in every direction, and validate the result against EN 16931 before it goes out.

Verified 12 actions API key available

finaX website Platform Documentation Capability data verified 2026-08-25

An invoice is finalized in the accounting system and its data reaches the agent on a schedule

Agent maps the record into the EN 16931 invoice model, filling the nine fields that cannot be omitted

Create CII XML returns the XML, or a failure naming the business rules that were not met

The agent compares the recipient's required national variant and release against the settings in use

Create PDF From CII produces a single file a person can read and a machine can parse

The billing owner receives the file with the variant, profile, and release it was built under

The billing owner confirms the settings for this recipient before the file leaves

What This Integration Enables

finaX is not an accounting system, and treating it like one is the fastest way to misuse it. It holds no customers, no ledger, and no invoices of its own. It is a stateless conversion and validation layer for European electronic invoicing: it turns a JSON invoice model into CII or UBL XML, welds that XML into a PDF to produce a ZUGFeRD or Factur-X file, reads any of those back into the model, and checks the result against EN 16931 on the way. Twelve operations, none of them a write to a system of record. That is the whole product, and it is why this connector sits underneath whatever books you already run rather than beside them.

The value for FlowRunner agents is that compliance becomes a step in a flow instead of a project. An agent finalizing an invoice can produce the compliant artifact in the same run, and a failure is legible rather than mysterious: validation happens before generation, and a rejected invoice comes back naming the business rules that failed by their identifiers in the standard, which can be looked up directly. On the receiving side, an agent can parse whatever a supplier sent without knowing which format it was, and extract the original embedded XML unchanged for archiving. Because nothing here is stored and nothing here is irreversible, the judgment worth reserving for a person is not a deletion. It is the question of what compliant means for this particular recipient, and FlowRunner's human-in-the-loop design is how that question gets asked once rather than never.

Without FlowRunner

Compliance discovered at the recipient The first sign a field was missing is a rejection from the receiving authority

Two files to keep in step A readable PDF and a structured XML are produced separately and can drift apart

Supplier formats handled one at a time A CII document and a UBL document take different handling at the point of receipt

With FlowRunner

Compliance checked before generation The document is validated against the standard first, and a failure names the rules by their identifiers

One file carrying both The structured XML is embedded inside the PDF, so the readable and machine copies cannot diverge

Supplier formats normalized on arrival Whatever a supplier sent is parsed into one model without the flow having to know which shape it was

Use Case Scenarios

An invoice that arrives acceptable the first time

An invoice is finalized upstream. The agent maps the record into the EN 16931 model, which is large enough that most of the work is mapping rather than transport, and calls Create CII XML. If the invoice is incomplete there is no document at all, only a failure listing the rules that were not met, so the agent has a precise repair list rather than a rejection notice weeks later. Create PDF From CII then produces the ZUGFeRD file, with the XML embedded so the human-readable and machine-readable copies are the same document. The file is archived to Box and referenced back on the source record. Where the business already generates invoices it is happy with, Merge PDF And XML does the same job in reverse: it welds the XML into your own PDF, so the design stays yours.
Supplier documents normalized on arrival

Suppliers send whatever their own systems produce. Parse XML File works out whether a document is CII or UBL and returns the model either way, which is the right operation for an inbound queue that cannot predict its input. For a ZUGFeRD PDF, Parse ZUGFeRD PDF gives the model directly. The agent reads the supplier, the totals, and the line detail, matches them against the purchase order, and routes the exceptions to the cost center owner in Slack. Two operations exist for the cases where the model is the wrong answer. Extract XML From ZUGFeRD PDF returns the original embedded XML unchanged, which is what an archive should hold. Extract Metadata From ZUGFeRD PDF returns only the metadata block, which is the cheapest way to ask what kind of file this is before deciding to parse it at all.
A validation sweep before a mandate deadline

A public-sector customer announces a format requirement with a date on it. Rather than finding out one invoice at a time, the agent runs the back catalog through generation as a check: for each recent invoice it builds the model and calls Create CII XML, recording which documents pass and which fail and on which rules. Nothing is sent. The result is a list of the data problems that will block invoicing, grouped by cause, most of which turn out to be a handful of missing fields on customer records rather than anything about the invoices. The billing team fixes the records. Invoices produced afterwards in FastBill or any other system pass on the first attempt, because the failure was found while it was still cheap.

Human-in-Loop Highlight

Nothing in this connector destroys anything, because finaX stores nothing. The irreversibility lives one step downstream, when the file reaches a recipient who either accepts it or does not, and a rejected e-invoice to a public authority is an unpaid invoice plus a resubmission cycle running at the recipient's pace rather than yours. Three settings decide that outcome and none of them will ever produce an error. The national variant and the profile both default to the German public-sector specification, which is right for a German authority and wrong for a PEPPOL recipient elsewhere. The release version defaults to the latest, and public-sector recipients frequently lag it. And Create PDF From UBL converts to CII first, so the XML inside the finished PDF is not the XML that was submitted, which matters if anything downstream is checking a signature or an exact match. So the agent generates freely and stops at the settings. On the first document to a new recipient, or on any change to variant, profile, or release, it posts: "First XRechnung document for Landesamt Nord. Built under XRechnung, latest release, CII embedded. Their portal notice names an older release. Send under the current settings, or pin the version they published?" One answer covers every invoice to that recipient afterwards. Routine conversions under settings already confirmed run unattended, because a gate on every file is a gate nobody reads. One further limit belongs in the same conversation: Merge PDF And XML rejects an obviously unsuitable PDF but the vendor states it does not perform a full conformance check, so passing that call is not proof your PDF conforms.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

12 actions

Generate XML

Create CII XML Turns the invoice model into CII XML, the shape that a ZUGFeRD PDF embeds. Validation runs first, so an incomplete invoice produces a rule list rather than a partial document.
Create UBL XML Turns the invoice model into UBL XML, the shape PEPPOL networks generally move. The national variant is a setting on the call, not an assumption.

Parse

Parse CII XML Reads a CII document into the invoice model.
Parse UBL XML Reads a UBL document into the invoice model.
Parse XML File Works out which of the two a file is and parses it accordingly. The right operation for an inbound queue that cannot predict what a supplier will send.
Parse ZUGFeRD PDF Reads the invoice model out of a ZUGFeRD or Factur-X PDF, normalizing the embedded document along the way. Running one real supplier file through this is the fastest way to learn the model's shape.

Generate PDF

Create PDF From JSON Produces a ZUGFeRD PDF straight from the invoice model, generating both the readable document and the embedded XML in one step.
Create PDF From CII Produces a ZUGFeRD PDF from CII XML you already hold.
Create PDF From UBL Produces a ZUGFeRD PDF from UBL XML. The conversion runs through CII first, so the XML embedded in the finished file is not byte for byte the XML supplied.
Merge PDF And XML Embeds CII XML into your own PDF, so a business that is happy with its invoice design keeps it and still ships a compliant file. The vendor rejects an obviously unsuitable PDF and states that it does not perform a full conformance check, so a successful call is not a conformance certificate.

Extract

Extract XML From ZUGFeRD PDF Returns the embedded XML exactly as it was, unchanged. The operation an archive or a pass-through should use.
Extract Metadata From ZUGFeRD PDF Returns only the file's metadata block. The cheapest way to ask what kind of document this is before deciding whether to parse it.

Frequently Asked Questions

What can FlowRunner do with finaX?

FlowRunner agents can run Create CII XML, Create UBL XML, and Parse CII XML in finaX, plus 9 more actions.

Does connecting finaX to FlowRunner require OAuth?

No. finaX connects to FlowRunner with an API key, no OAuth flow required.

Can finaX trigger a FlowRunner workflow automatically?

finaX doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with finaX

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us