Why Do Latvian Peppol E-Invoices Fail Before Sending?

On a first structured e-invoice, what breaks is almost always the format and the address — not the amount. A PDF attached to an email is not a structured e-invoice in Latvia: what counts is an XML file whose structure follows the Peppol BIS Billing 3.0 specification. Six things typically stop an invoice before it reaches anyone: a buyer electronic address that is missing or has no scheme identifier, a missing buyer reference or purchase order number, a wrong or missing specification identifier, a VAT category with no exemption reason, totals that don’t reconcile with the lines and the VAT, and a missing payment account. These are fatal rules — the invoice doesn’t arrive, it bounces back as an error message. Check the XML before you send it in the European Commission’s e-invoicing validator.

Who Actually Has to Receive an E-Invoice in Latvia?

Latvia phased the requirement in, and the phasing is where most of the confusion sits. According to the Latvian tax authority VID, structured e-invoices have been mandatory since 1 January 2025 in dealings between the public sector and companies registered in Latvia — the G2G, B2G and G2B segments. The Accounting Law states that an invoice a company submits for payment to another company registered in Latvia, meaning the recipient of the goods or service, is issued as a structured e-invoice. The same overview ties 1 January 2026 to a second obligation: in those same segments, the invoice data must also be reported to VID. Domestic B2B follows only on 1 January 2028, when invoices must be issued as e-invoices and reported to VID at the same time. Between 1 January 2026 and 31 December 2027, reporting B2B data is voluntary. So January 2026 did not make every B2B invoice mandatory.

Which B2B invoices fall under the obligation is set out in Section 11 of the Accounting Law (Grāmatvedības likums): paragraph 14 covers the invoice submitted for payment to another company registered in Latvia, and paragraph 16 lists the limited exceptions, which are tied to the type of document and the system used. There is no turnover threshold in there.

The second misunderstanding is treating Peppol BIS Billing 3.0 as a channel. It is a format. Cabinet Regulation No 749 of 9 December 2025, which entered into force on 1 January 2026, lets you choose the channel: e-adrese — the official electronic address in the state portal — an operator’s channel, or another route the parties agree on, such as a system-to-system integration or email. An invoice in Peppol format is not automatically an invoice that travelled over the Peppol network. And the reverse holds too: in Latvia, the Peppol network is not the only permitted route.

What Happens When Your ERP Sends the Invoice?

Sending over an API looks like this in practice:

1. Your ERP — the accounting or business software — builds a UBL 2.1 XML file from the invoice, following the EN 16931 data model and the Peppol BIS Billing 3.0 rules.
2. The file is validated: first the XML schema (XSD), then the business rules, which is the Schematron check.
3. The invoice travels through the chosen channel to the recipient’s electronic address, and the channel returns a sending status.
4. The VID copy goes either as an XML file uploaded to EDS or straight from the accounting software through the E-Invoice API V2; VID accepts XML only, with no attachments.
5. The last step is checking statuses on both sides — the recipient’s and VID’s.

Why the First Error Is the Address, Not the Amount

In Peppol BIS Billing, both the seller’s and the buyer’s electronic address (EndpointID) are mandatory, and each one needs a scheme identifier — the code that says what kind of identifier it is, for example a VAT number or a company registration code. An address without a scheme identifier is a fatal error, not a missing nicety.

Don’t derive the buyer’s address yourself. Ask the buyer for it in writing and check three things: the identifier, its scheme, and the channel the buyer actually receives invoices in. If your buyer receives invoices through e-adrese, a technically flawless XML sent into an operator’s channel helps nobody. An Estonian company invoicing a Latvian budget institution should settle the institution’s status and details before the first invoice, not after the first bounce.

Which Header Fields You Shouldn’t Leave to the Software

Peppol’s fatal rules require, among other things, the specification identifier, the invoice number, the issue date, the invoice type code, the currency, seller and buyer names, postal addresses and country codes, the document totals, and at least one invoice line. Several of these arrive as software defaults — which is exactly why nobody reviews them.

Two values deserve their own look. The specification identifier (CustomizationID) and the business process identifier (ProfileID) have to match the BIS version in force: OpenPeppol published the Peppol BIS Billing 3.0 May 2026 release on 20 May 2026, and it is mandatory from 17 August 2026. If your software still generates an older version, you usually find out from the recipient’s error message.

Why a Correct Invoice Lands in the Wrong Workflow

A Peppol invoice must carry either a buyer reference or a purchase order number. One of the two is required. The buyer reference isn’t decoration — it is the recipient’s internal routing key, the value that sends the invoice to the right cost centre, contract or approver.

This is where you get the quiet failure a validator never catches. The XML is correct, the invoice arrives, and then an invoice with the wrong reference sits in front of the approval queue while the payment slips. Copy the value the buyer gave you character for character — spaces and hyphens count — and store it in your ERP against the customer or the contract, not in a manual field on a single invoice.

VAT and Totals: Where the XML Stops Forgiving

VAT is where most first invoices fail. Every invoice line needs a line identifier, the invoiced quantity, a unit of measure code, the name of the goods or service and the net price, and the country, currency and VAT category fields have to use the prescribed code lists. Your own abbreviations and free text don’t work here.

The usual failures:

• Reverse charge with no reason given. Under the reverse charge the VAT amount must be zero and the invoice must carry the matching exemption reason code or text. Exempt categories and those outside the scope of VAT also need zero plus their own justification.
• Totals that don’t reconcile. Peppol checks that the invoice total with VAT equals the net total plus VAT, and that the amount due reconciles with any amount already paid and the rounding amount.
• Rounding. The tax per VAT category has to be calculated and rounded to two decimal places. Leaving a third decimal ends in an error message.
• Discounts and charges. A document-level allowance or charge has its own reason field, and both have to show up in the calculation of the totals.
• Missing payment account. If payment is by credit transfer, the payment account identifier is mandatory. A stale IBAN or a missing payment reference is not a cosmetic gap — it blocks sending.

The Sending-Day Checklist

Before the first send, walk this through once by hand, then keep it as a standing routine.

1. Validate the XML. VID recommends checking the file before submission with the European Commission’s validator. Pick the right document type in the tool — UBL invoice or UBL credit note — and switch on both the XML schema and the Schematron checks.
2. Check the sending status. The channel has to confirm that the invoice reached the recipient’s address.
3. Check the VID status. VID shows as rejected those files whose processing ended in an error, because they failed the Peppol standard conformance check (XML, XSD and Schematron) or the virus scan.
4. Don’t send a duplicate. An e-invoice is reported to VID once, no later than five working days after the day it was sent. If the invoice has already reached VID, don’t submit it again through another channel.
5. Fix errors with a credit note. Once an invoice is on its way, you don’t pull it back. The correction goes out as a credit note or a corrective document referencing the original. Where there is a reference to a preceding invoice, the preceding invoice number must be present too.

In What Order Should You Fix the Error Messages?

Errors come in layers, and it pays to work top down. First the XSD errors, meaning the XML schema: a wrong element name, a missing namespace, elements in the wrong order. Until the schema is valid, the file never reaches the business rules at all. Then come the Schematron rules, whose identifiers tell you where to look: EN 16931 business rules concern the standard’s own requirements, Peppol’s own rules the restrictions in that specification, and the UBL syntax rules (those flagged UBL-SR, for instance) how many times a single element may appear. The specification grades its rules by severity, and “fatal” means a blocker — warnings can wait, fatal errors cannot.

Once one bad invoice has been through the loop, write down what exactly was wrong and where that value comes from in your ERP. The second time round, the same error is usually a data model question, not an attention question.

Also available in: eesti keeles · latviski

Last reviewed: 21 September 2026