attestwireNobody knows what BR-DE-15 means.
Check an XRechnung or Peppol invoice and find out which rule it failed, which field that means, and what to put there.
BR-DE-15 (n., XRechnung) a rule that says your invoice needs a buyer reference, which is a number your customer has and never mentioned. Ask them for their Leitweg-ID. Put it in field BT-10. Send it again.
Paste my invoicePaste the invoice. Every code gets looked up.
UBL or CII, XRechnung or Peppol. One line per problem, with the field to change. The checker is free, needs no account and runs in your browser.
A sample result. Yours will name your invoice’s own fields.
The dictionary.
Every code a German or Peppol invoice can be rejected with, defined like a word. The three codes people look up most:
BR-DE-15n.
a reference your customer never gave you. The buyer reference. Your customer has it. Ask.
BR-CO-10n.
the sum of your lines is not the sum of your lines. Round each one to two decimals first, then add.
a reminder, not a rejection. Your invoice doesn’t say when the work happened. Add a date. Not fatal. Still add it.
If you’re building something.
The dictionary is also a library. Same rules, same fixes, from your own code, over HTTP, or as tools your AI assistant can call.
npm install @attestwire/en16931The library · The API · MCP · Pricing
Questions people ask first.
Is it private? The browser checker never uploads your invoice. Hosted checks, which need an API key, send data to Attestwire.
Can I check a PDF? The browser checker accepts XML, not PDF files. Pull the XML out of the ZUGFeRD or Factur-X file first; developers can use extractFacturX in the library, which reads the PDF and does not build a PDF. How to extract the XML.
Does a pass mean the portal will accept it? It means the invoice data follows the rules. Portals also check how the XML file is built (its schema and Schematron), which we don’t, so a pass does not guarantee acceptance. What we don’t check.
Building an integration? Get your API key or connect MCP.