Scope

Where the transmission boundary sits: generate and validate are live, you deliver over your channel, and managed delivery is in build.

Beliq is the platform for European e-invoicing. Its correctness engine builds a structured e-invoice, validates it against pinned rule packs and schemas (the authority’s own rules where the badge is Authority-checked), converts between the EN 16931 syntaxes, and parses a document back into canonical data.

Generate and validate are live today. Getting that document onto the wire is a separate step for now: Beliq builds and checks the file, and you transmit it over the channel you already use. Managed delivery is in build. This page sets out where that line sits today, and the principle that holds wherever it moves: you are never locked to one network.

• Generate a valid e-invoice from your data, as XML or as a Factur-X / ZUGFeRD PDF/A-3.
• Validate an existing invoice and return a pass or fail against the rule packs and schemas pinned for its format, with the specific rule IDs that failed.
• Convert across the EN 16931 family (CII, UBL, XRechnung, Peppol BIS Billing 3.0) without dropping structured data.
• Parse an invoice into canonical, machine-readable fields.

Every result is judged against a ruleset pinned by version to its authority. See How verification works.

Beliq does not put the invoice on the wire. Specifically, it is not:

• a Peppol Access Point (it does not route documents over the Peppol network);
• a Plateforme Agréée (PA) for the French reform;
• an SDI submitter for Italy;
• a KSeF submitter for Poland;
• a government portal, an email relay, or an EDI gateway.

It also does not accept every field the standard defines. EN 16931 has 164 business terms and the invoice object has a field for 139 of them. An invoice needing one of the other 25 has no field to send it in: Beliq works 6 of those out from the rest of the request, and the remaining 19 cannot reach the document through /v1/generate today. EN 16931 field coverage lists all 164 term by term. Validation is unaffected: /v1/validate judges a document you supply against the authority’s full ruleset, every term included.

Beliq hands you a correct, validated file. Getting that file to your buyer or to a tax authority is the transmission step, and today that runs over the channel you already use. Managed delivery is in build. It stays provider-independent when it lands: certified networks selected per destination and kept interchangeable, so you are never locked to one provider.

Whatever carries your invoice, that choice stays yours. That is the throughline today, and it stays the throughline once managed delivery ships.

• Transmission is country-specific and regulated. Each mandate (France, Italy, Poland, and the Peppol network across the EU) has its own accredited channels, onboarding, and legal responsibilities, and they move on their own timelines.
• The transmission vendor is a relationship you own. Access Points, Plateformes Agréées (PA), and portals are yours to choose. Beliq does not force your routing through us, so changing your transmission vendor never touches your compliance layer.
• Correctness is the foundation. Pinning every ruleset to its authority and re-verifying it on a calendar is a full-time job, and it is what makes a Beliq verdict something you can prove. That is the base the rest of the platform builds on.

So Beliq works with whichever transmission vendor you trust today, and managed delivery, when it arrives, keeps that same door open across networks.

A typical flow looks like this today:

1. You call POST /v1/generate or POST /v1/validate.
2. You get back the file and its verdict.
3. You hand that file to your Access Point, Plateforme Agréée (PA), or portal for delivery.

If you want to automate that hand-off, the integrations plug Beliq into the rest of your stack. The delivery leg runs through your chosen channel. When managed delivery ships, Beliq can run that third step for you over a certified network chosen for the destination; until then it is yours to run.

Invoice content is processed in memory and is not persistently stored or used to train models; any temporary file a request creates is deleted as soon as it completes. What Beliq does keep is a record of each request: the operation, the format, the outcome, the timing and, where the request validated a document, the validation findings. Your dashboard’s request history and your usage count are built from that record.

Managed delivery will change this, and it is not live yet. A document Beliq delivers or receives for you has to be held until it has been handed on, so it is stored encrypted. Beliq deletes its copy of the document’s bytes 90 days after the transmission finishes, and no later than 180 days after Beliq accepted it, whichever comes first. Both periods are Beliq’s own choice, not a legal or network rule. A deleted document can remain in Beliq’s database backups for up to 30 more days, and up to 45 days in the off-site copy. The delivery partner that carried the document keeps its own copy, on its own retention period.

See the Trust Center for data residency and subprocessor detail.