What Attestwire cannot do

Every tool has limits. Most vendors do not publish theirs. You find out when an invoice is rejected. Here are ours.

Read this page before you integrate, not after. If one of these limits blocks you, say so at hello@attestwire.com. We would rather lose the sale now than fail you in production.

The formats we do not produce

Attestwire writes XML. It does not write a PDF. EN 16931 allows two XML formats: UBL and CII. We write both. That part is no longer a limit.

The limit is the PDF. ZUGFeRD (Germany) and Factur-X (France) are CII XML held inside a PDF/A-3 file. We give you the CII XML. We do not build the PDF around it, we do not attach the XML under the file name those formats require (factur-x.xml, or xrechnung.xml for the XRECHNUNG reference profile), and we do not set the /AFRelationship value Germany requires.

So please read this next line twice. The file you get from us is a CII XML file. It is not a Factur-X document and it is not a ZUGFeRD document. If you send it to a customer as one, it will be wrong. Take our XML to a PDF/A-3 library and build the real file there.

There is one more shape we refuse. peppol-bis-3 and xrechnung-ubl have no CII form at all — Peppol BIS Billing 3.0 does not define one — so asking for CII on those two profiles throws an error instead of handing you a document a portal would reject.

Here is the whole map, so nobody has to guess. Both the library and the hosted API write:

• xrechnung-ubl and peppol-bis-3 — UBL 2.1 only.
• xrechnung-cii — CII only. KoSIT has judged our output for this one.
• facturx-en16931 — CII only, and the CII payload only. Not KoSIT-verified: it states the core EN 16931 identifier, which matches no XRechnung scenario, so KoSIT answers "no scenario matched" rather than a verdict. And it is still not a Factur-X file, because there is no PDF.
• en16931 — the core standard. The library writes it in either syntax; over the API it comes back as UBL.

Validation covers all five of those profiles, in both syntaxes.

Where Attestwire fits, and where it does not

It fits Peppol and UBL work. That means Belgium and the Netherlands, which run on Peppol BIS 3. It also means German public-sector invoicing (B2G), which runs on XRechnung UBL.

It now also fits XRechnung CII. Many German senders use CII rather than UBL. We write those documents and we read them, and the KoSIT validator has judged ours.

It still does not fit ZUGFeRD or Factur-X invoicing. That work needs the PDF, and the PDF is the part we do not build. You can use us for the XML inside it and something else for the container. If you want one tool that hands you a finished Factur-X file, this is not that tool today.

What we can read, and what we cannot

We read a UBL or CII invoice file. Hand us the XML and we read it into the invoice model, then check it. We also list every part of the file that did not reach the model, so nothing goes missing in silence.

We cannot open a PDF. If an invoice arrives as a Factur-X or ZUGFeRD PDF, we cannot read it. Extract the XML first with another tool.

This has one consequence worth stating plainly. Reading a file is still a pre-flight check, not an authority. We check the data we read out of the document, not the document itself, so a few rules about the XML — BR-01, BR-DE-13 and BR-DE-21 — do not run. A document we accept can still be rejected by the official validator.

Documents we do not build

Credit notes used to be on this list. They are not any more. Set the document type code to 381 and you get a real UBL CreditNote — its own root element, its own schema, its own line elements — or, in CII, the same document with the type code changed, because CII has no separate credit-note document. We read them back too. Two fields cannot come along: a UBL credit note has no place for a payment due date unless you also send payment instructions, and no place at all for a project reference. You get told, in both cases, rather than losing the field quietly.

Debit notes are not supported. UBL has a document for them and EN 16931 does not say how to fill it in, so there is nothing to build against.

Rules we do not run

We implement every rule of EN 16931, the German XRechnung CIUS and Peppol BIS 3 that the JSON model can express. What is left out is below. It is a list, not a percentage.

• Factur-X and ZUGFeRD as a PDF. Factur-X and ZUGFeRD are CII XML inside a PDF/A-3 container. The library writes the CII XML and nothing else. It does not build the container, does not attach the XML under the required file name (factur-x.xml, or xrechnung.xml for the XRECHNUNG reference profile), and does not set the /AFRelationship value Germany requires. So the output is a CII XML file. It is not a Factur-X or ZUGFeRD file, and a reader who treats it as one will be wrong. It also cannot open a Factur-X or ZUGFeRD PDF. Take the XML to a PDF/A-3 library to make the file.
• Validating the XML itself. The library reads a UBL or CII file into the input model, then checks the model. That is a pre-flight over the parsed input, not a schematron over the document. Rules that constrain the XML rather than the input — BR-01, BR-DE-13 and BR-DE-21 on BT-24 — still do not run. A document we accept can still be rejected by the reference validator.
• Debit notes. UBL has a DebitNote document and EN 16931 has no binding for it, so there is nothing to implement against. Credit notes are a different answer and used to be on this list: since 0.5.0 they are generated, read and validated in both syntaxes, and the two rows below are what is left of that gap rather than the gap itself.
• The project reference on a UBL credit note. cac:ProjectReference is not in UBL-CreditNote-2.1.xsd at all, so no conformant UBL credit note can carry BT-11 by any means. This is a hole in the syntax, not in the library: the CII binding keeps the reference. Supplying one on a UBL credit note raises a finding naming what will be missing, rather than dropping the field in silence. The payment due date (BT-9) is the same story with a way out — it moves into the payment instructions group.
• XPaths on credit-note findings. Every finding carries an xpath, and it is a fixed string per rule. Most of them still read /ubl:Invoice/… on a credit note. The rules that exist because the document is a credit note name /ubl:CreditNote correctly; the rest do not. An xpath here is documentation of where a term lives, not a resolved location in your document.
• Peppol rules inside the XRechnung schematron. KoSIT’s XRechnung schematron runs a few PEPPOL-EN16931 rules for both syntaxes, PEPPOL-EN16931-R040 among them. This build runs its Peppol rules only when the profile is peppol-bis-3. So R040 does not run here for an XRechnung invoice, even though KoSIT runs it. This is not new; the 2026-08-11 KoSIT run is what named it.
• Rules the generator controls. A handful of rules constrain XML this library writes from the profile rather than from anything you send, so there is no input that can fail them. They belong to a document-validation entry point, not to an input pre-flight.
• Four rules the regulator does not test either. BR-CO-05 to BR-CO-08 require a reason code and a reason text to mean the same thing, which has no mechanical test; the reference schematron binds all four to true(). BR-CO-25 is in neither schematron, so implementing it would reject documents the authority accepts.
• VAT category B, and the Extension and CVD profiles. Split payment (Italy) has no rule family to implement, so a line carrying it is refused rather than passed silently. BR-DEX-* and BR-DE-CVD-* apply to customization ids this build does not emit.
• National Peppol rule sets. NO-R-*, DK-R-*, SE-R-* and the rest are country overlays on top of the BIS rules, each a project of its own. A document this library accepts is checked against the core, XRechnung and Peppol BIS sets, not against a receiving country’s extra requirements.

One item there deserves a plain-English restatement, because it decides whether a document is accepted in a given country. National Peppol rules are not run. Norway, Denmark, Sweden and others add their own requirements on top of Peppol BIS 3. We check the core, XRechnung and Peppol BIS sets. We do not check a receiving country's extra requirements.

We do not send invoices

Attestwire is not a Peppol access point, a French PDP or a KSeF connector. We build the document and we check it. Something else has to deliver it. This is deliberate and it will not change: transmission is a regulated business with different economics.

The output is shaped to hand straight to an access point, so this is a clean seam and not a gap.

How far our testing goes

We run the official KoSIT validator 1.6.2 with the XRechnung 3.0.2 configuration over the release fixtures we ship. On 11 August 2026 all 11 passed with zero messages: five XRechnung UBL documents and six XRechnung CII documents.

Be careful how you read that. It is a conformance check on a small number of documents. It is not a parity suite. It says nothing about paths those fixtures do not exercise.

It also says nothing about Factur-X. A Factur-X document names a specification that KoSIT has no scenario for, so the validator replies "no scenario matched" instead of judging it. Only the six XRechnung CII documents were checked by a CII Schematron. Do not read "KoSIT checked our CII" as "KoSIT checked our Factur-X".

You do not have to take our word for it. The fixtures and the script are in the repository, and you can run them yourself. See how this is built and the source.

Certifications and support we do not have

There is no SOC 2, no ISO 27001 and no third-party penetration test. There is no support SLA on any plan, and no uptime percentage in the terms. If your procurement process requires one of these, we do not meet it today.

We also do not store your invoices. That is normally a good thing, but it has a cost: we cannot help you find last Tuesday's document, because we never kept it. Do not build as though we could. The security page says exactly what happens to a payload.

What a pass actually means

A result of valid: true means our checks found no fatal error. It does not mean a tax authority, a portal or your customer will accept the document. It is not tax or legal advice. The terms say this too, and they say it first rather than in a footnote.

This list comes from the same source as the library's own changelog, so the page and the code cannot drift. If something here ships, it comes off this page in the same change. Pricing · About Attestwire.

Last updated 13 August 2026. If this page changes materially we will say so here rather than silently swapping it.