SoftbooqAccounting handoff / Europe
Producing a compliant e-invoice costs nothing. Vendors would rather you did not know
PEPPOL BIS Billing 3.0, the format behind the EU e-invoicing mandates, is an open standard built on UBL 2.1. Generating a compliant document needs no government login, no paid API and no signup. Only the network hop that delivers it does, and those credentials are yours.
What the file actually is
- 1The document, produced offlineA UBL 2.1 XML file conforming to PEPPOL BIS Billing 3.0, which is the EU norm EN 16931 made concrete. Accepted across roughly thirty countries: the whole EU, plus Norway and Iceland, and adopted beyond Europe. Nothing about producing it is gated.
- 2The transmission, through an access pointEither your own channel to the national authority (SdI in Italy, KSeF in Poland) or any PEPPOL access point. This is the only step needing credentials, and they are your own taxpayer registration rather than something a software vendor buys.
- 3The archiveThe XML is the legal original, not the PDF a human reads. Retention rules are national and typically run to years, so the file that must survive is the one nobody looks at.
The five things that go wrong
None of these are exotic. Each one is a default that is correct almost everywhere else in software, and wrong here.
On a printed invoice, a zero-rated line and an exempt line both show 0.00 and look identical. EN 16931 treats them as different VAT categories, and putting the wrong code on a line is a content error rather than a formatting one.
The categories are S for standard rate, Z for zero rated, E for exempt, AE for reverse charge, K for intra-community supply, G for export outside the EU and O for outside the scope of VAT.
Categories E, AE, K, G and O must carry an exemption reason. A document that claims exemption without stating why is incomplete, and a validator will say so.
The reason text is jurisdiction specific and the legally correct sentence is not ours to invent. Softbooq uses the wording on the tenant’s own tax code and only falls back to a generic sentence when that code has no usable name, because "Reverse charge, art. 196 VAT Directive" is a legal statement, not a label.
Many public sector buyers reject an invoice with no BuyerReference, because it is the field their system routes on. It is not a formality and it cannot be guessed later, so it has to be known before you invoice. In Softbooq it is kept on the customer record (Buyer reference / Leitweg-ID) and added to that customer’s e-invoices.
A corrective document carries a billing reference to the original invoice. Without it, the receiving system has a standalone document and no way to match it. Softbooq writes that reference on a corrective invoice, and on a credit note, which downloads as a Peppol credit note naming the invoice it credits.
The monetary totals, the tax subtotals per category and the line extension amounts must agree to the cent. Receiving systems validate this, so a rounding shortcut that a human would accept on a PDF fails outright here.
What is actually gated, and what is not
The pricing around e-invoicing tends to blur two different things. Producing a compliant document is an open standard and costs nothing: UBL 2.1 is published, PEPPOL BIS Billing 3.0 is published, and any software can emit a conforming file.
Sending it to a specific tax authority is where a credential appears, and that credential is the business’s own taxpayer registration. A vendor charging for "e-invoicing support" is charging for the transmission, or for the convenience, and it is fair to ask which.
The tax breakdown is per category, not per rate
It is tempting to group the tax subtotals by percentage, because that is what an invoice layout shows. EN 16931 groups by category and rate together, so a zero percent standard line and a zero percent exempt line are two separate breakdown groups even though both show zero.
Getting this wrong produces a document that balances and still misstates the nature of the supply, which is the kind of error that survives your own testing and surfaces at the receiving end.
The XML is the original
The habit of treating the PDF as the invoice and the XML as an export is the wrong way round under these mandates. The structured document is what is legally exchanged and archived; the human readable rendering is a convenience.
Practically, that means the XML has to be generated from the same data the invoice was posted from, not reconstructed afterwards from a layout.
EN 16931 is the common core, and countries add their own requirements over it: an extra identifier, a national code list, a specific transmission route. The core document being correct does not by itself make a filing correct in a given country.
So validate against the target country’s own validator before the first real submission. The document structure here is the reusable part, and it is deliberately the part that costs nothing.
Common questions
Do I need to pay for e-invoicing software?
Not to produce the document. PEPPOL BIS Billing 3.0 is an open standard built on UBL 2.1 and any software can emit a conforming file offline. Payment enters at transmission, through an access point or a national portal, and the credentials there are your own taxpayer registration rather than a vendor licence.
What is the difference between zero rated and exempt?
Both show 0.00 on paper and they are different EN 16931 categories: Z for zero rated, E for exempt. Exempt also legally requires a reason, as do reverse charge, intra-community supply, export and out of scope. Using the wrong code is a content error that a validator will reject.
Why was my invoice rejected for a missing buyer reference?
Many public sector buyers route on BuyerReference and reject documents without it. It has to be captured when the order is taken, because it is the buyer’s own identifier and cannot be reconstructed at invoicing time.
Is the PDF or the XML the real invoice?
The XML. Under these mandates the structured document is what is exchanged and archived, and the PDF is a human readable rendering of it. That is also why the XML should be generated from the posted invoice data rather than rebuilt from a layout.
Softbooq exports this file directly from posted journal entries, with the encoding, the sign convention, the date format and both decomposition shapes handled explicitly. The behaviour is covered by automated tests that run before every release.
See the Finance module