ARLing

How to Create a UBL Invoice Without an ERP System

ARLing s. r. o. · 11 September 2026

If your accounting software cannot produce a proper electronic invoice yet, you can still create a UBL invoice by hand, field by field, once you understand what the format actually demands. An electronic invoice is not a PDF with a tidy layout: it is a document issued, sent and received in a structure built for automated processing, using the semantic data model of EN 16931 written in the UBL 2.1 syntax, and neither an e-mailed PDF nor a scanned paper invoice meets that definition. Many small businesses assume this needs a full accounting system or a paid invoicing platform, when the underlying rules are public, including the right identifier for your own company. This article walks through what actually has to go into the file: the invoice number and totals the core standard checks first, the extra layer of rules that Peppol BIS Billing 3.0 adds on top of it, the VAT category codes every line needs, and the identifier that lets a Slovak business be found on the delivery network at all.

What Counts as a Real Electronic Invoice

A file only counts as an electronic invoice when it is issued, sent and received in a format built for automated processing, not just for reading on a screen. The technical standard behind it is EN 16931, and it can be written in one of two syntaxes, UBL 2.1 or CII, while a PDF invoice attached to an e-mail, however professional it looks, and a scanned paper invoice both fail this definition because a computer cannot reliably pull structured data out of either one. That is the first thing to check before calling anything a UBL invoice: it has to be an XML file that follows the UBL 2.1 syntax, with every amount, date and identifier sitting in its own labelled field rather than inside a block of free text.

Inside the EN 16931 Data Model

EN 16931 does not just say an invoice needs a number and a total, it defines a full semantic data model: which pieces of information must appear on an invoice and how those pieces relate to each other. The schematron behind the standard splits this into two families of rules, the core business rules numbered BR-01 through BR-65, of which 58 actually exist in the current rule set, and the calculation and consistency rules numbered BR-CO-01 through BR-CO-26, of which 24 exist. The core rule BR-02 states plainly that an invoice shall have an invoice number, so a UBL file with an empty or missing invoice number field is treated as a fatal error and the file is rejected. The calculation rule BR-CO-15 checks that the invoice total with VAT equals the total without VAT plus the VAT amount exactly, which is the most commonly reported totals error.

The Extra Rules From Peppol BIS Billing 3.0

EN 16931 alone is not enough to send an invoice to another business over a delivery network. Peppol BIS Billing 3.0 is the country independent specification, a CIUS, that sits on top of it and narrows the same UBL 2.1 syntax into something every receiving system can process the same way. On top of the core EN 16931 rules it adds its own set, coded PEPPOL-EN16931-R and PEPPOL-COMMON-R, and the release from November 2025, numbered 3.0.20, contains 41 of them, some of which only matter for businesses outside Slovakia. One example shows how specific these rules get: PEPPOL-EN16931-R040 requires that whenever a discount or surcharge line states both a base amount and a percentage, the actual amount has to match their product exactly, so a UBL invoice built by hand needs that multiplication checked before it is sent, not after a partner's system rejects it.

VAT Codes and Your Business Identifier

Every invoice line needs a VAT category code from the UNTDID 5305 list, and EN 16931 only recognises a fixed set of them: S for the standard rate, Z for zero rated, E for exempt, AE for reverse charge, K for an intra community supply, G for export outside the European Union, O for not subject to VAT, and L and M for the Canary Islands and for Ceuta and Melilla. Each of the main categories carries its own group of calculation rules in the schematron, so picking the wrong code on a line does not just look wrong on paper, it fails a rule written specifically for that category.

On a Slovak invoice the S code usually points to the standard rate of 23 percent, with reduced rates of 19 percent and 5 percent applying to specific goods and services, and since 1 January 2026 some sweet and salty food items moved from the 19 percent rate up to the standard one, so a template copied from an older invoice can quietly carry the wrong figure. Once the invoice content itself is correct, the file still has to say who sent it: a Slovak business identifies itself on the Peppol network with the scheme code 0245 followed by its ten digit tax identification number, written as one string such as 0245:1234567890, which is neither the VAT number nor the company registration number and is easy to get wrong the first time nobody has filled it in before.

Frequently asked questions

Can I just send a PDF invoice instead of a UBL file?

No, and you do not need a PDF at all: what has to reach the recipient is an XML document that follows the UBL 2.1 syntax, since neither an e-mailed PDF nor a scanned invoice lets a computer extract that data automatically.

Do I still need the Peppol rules if the file already passes EN 16931?

Yes, if the file is going to reach a trading partner over the delivery network, because Peppol BIS Billing 3.0 adds 41 of its own rules on top of EN 16931 in its current release, and a file that passes the core standard can still fail one of them, such as the rule on discount amounts matching their stated percentage.

What is the fastest way to check the VAT code on each line before sending the file?

Match every line to one of the UNTDID 5305 letters EN 16931 actually recognises, such as S for the standard rate or AE for reverse charge, and then check the rate itself against what currently applies in Slovakia, since categories like sweet and salty foods have moved between rates before.

Conclusion

Building a UBL invoice by hand is doable, but every field above has to be right at the same time: the syntax, the EN 16931 numbering rules, the extra Peppol layer, the VAT category code and the network identifier, and a single wrong character in any of them is enough for a receiving system to reject the file. If checking all of this manually before every invoice sounds like too much to keep in your head, the ARLing e-invoicing overview page summarizes the EN 16931 and Peppol BIS Billing 3.0 rules described here.

Sources. The facts in this note are numbered after our internal fact list and were checked on the publication date. ARLing is not a bank; a clean check result is no guarantee that the bank accepts the payment. If a source has changed since, write to andrej@arling.sk and we will correct this page.