Latvia B2B E-Invoicing 2028: Is the VID API Mandatory?

No. Not every e-invoice needs to travel through VID’s API. That’s the mix-up: two separate obligations get treated as one. From 1 January 2028, every Latvia-registered business that issues an invoice to another business must produce it as a structured e-invoice and submit its data to Valsts ieņēmumu dienests (VID) — Latvia’s State Revenue Service. That duty comes from the Grāmatvedības likums (Accounting Law), whose original 2026 deadline was pushed back to 2028. A direct connection to VID’s API, an application programming interface that lets two software systems exchange data automatically, is only one of three permitted channels, set out in Cabinet Regulation No. 749 of 9 December 2025. Alongside it sit the official e-address and the operator channel. The period 2026–2027 is, in practice, a voluntary testing window, not yet the mandate itself.

Does every e-invoice have to go through the VID API in 2028?

This is where most of the confusion starts. The law sets two obligations at once: your business has to issue the invoice as a structured e-invoice, and it has to get that invoice’s data to VID. Neither requirement says how the data actually moves. That question is answered by Cabinet Regulation No. 749, which lays out three permitted routes. A direct API connection is actually what only a minority of businesses will need, since the e-address and the operator channel do that job for them automatically.

Who does the obligation from 1 January 2028 affect?

Who counts as an issuer

The duty covers everyone named in the Accounting Law: Latvia-registered companies, Latvian branches of foreign companies, permanent establishments of non-residents, and sole proprietors carrying out economic activity. The law sets no threshold: no turnover limit, no invoice-value floor, no VAT-registration test. So the obligation applies equally to a one-person business and a large group.

It’s an issuer-side obligation. Your business has to issue a structured invoice to another Latvian business and get its data to VID, regardless of whether the recipient is ready for it yet.

What’s exempt

The exceptions are narrow. They cover transactions documented through certified cash registers, invoices generated inside the systems of the Health Inspectorate and the State Employment Agency, and specific security and law-enforcement authorities.

Do the data for the recipient and for VID have to travel the same route?

Here’s a second point worth keeping separate. The channel that gets the invoice to your trading partner and the channel that gets the data to VID don’t have to be the same one.

The channel to your trading partner

Cabinet Regulation No. 749 lets trading partners agree on one or several delivery channels between themselves: the official e-address, an operator channel, or another agreed method, such as a system-to-system integration or even email.

The channel to VID

For getting data to VID, there are three specific routes: the official e-address, whose information system sends the e-invoice message to VID automatically; an operator channel integrated with VID’s system through the API; or VID’s own EDS API (Elektroniskā deklarēšanas sistēma, Latvia’s Electronic Declaration System interface) or its file-upload function. If you use the e-address or an operator, your own system never has to talk to the API at all. The intermediary does that work for you. VID confirms in its FAQ that accounting software can also transfer an e-invoice file in XML format straight to VID, a third option alongside the first two, not the only path.

What does the direct E-Invoice API V2 integration require?

If you decide the direct route makes sense, say because your invoice volumes are high and you want the whole process automated, VID runs this through its E-Invoice API V2 service. Before your developers can start building, several steps come first.

Steps before you start building

• Generate an invoice that matches the structured e-invoice XML format.
• Agree with your trading partner on the channel that will deliver the invoice to them, which can differ from the route the data takes to VID.
• Create an API certificate or an API atslēga (API key) in EDS, with Dokumentu API (documents API) permissions attached.
• Connect your accounting or ERP software to VID’s API, using the OpenAPI 3.0 specification and Swagger components; this work is usually done by your software vendor, not your accountant.
• Send VID a copy of the invoice through the designated channel and log the outcome, so that if a dispute comes up later you can prove when and how the invoice was submitted.

Limits worth knowing

One detail developers tend to overlook: the API key is valid for a maximum of 90 days, after which it has to be regenerated. The maximum allowed size for a single e-invoice is 20 MB.

What’s the technical minimum for a structured e-invoice: XML, UBL 2.1 and PEPPOL BIS Billing 3.0?

A structured e-invoice isn’t a PDF, even though the two can look identical on screen. Under the law, a structured e-invoice is one a machine can read and process automatically. Its file format is XML (Extensible Markup Language), matching the standard LVS EN 16931-1:2017 and the technical specification LVS CEN/TS 16931-2:2017. VID accepts data whose XML structure follows the UBL 2.1 (Universal Business Language) and PEPPOL BIS Billing 3.0 core invoice usage specification (CIUS).

Using the actual Peppol network isn’t mandatory in itself. What’s mandatory is that your file structure matches the same specification Peppol uses. If you’re currently sending partners a PDF invoice, that won’t magically become compliant in 2028. You need a separate XML file matching the data model, even if a human-readable PDF still rides along with it.

Is e-invoice submission to VID real-time?

An e-invoice has to reach VID once, no later than five working days after the day it was sent. That’s after-the-fact submission, not real-time reporting.

If a fault occurs in your company’s or your operator’s information system, you have to report it in EDS no later than the next working day after the deadline passes, and submit the invoice within three working days of the fault being fixed. If the delay comes from another cause, that also has to be logged in EDS, with the invoice submitted within 30 calendar days of identifying the cause.

The penalty for breaching the requirements around producing, registering or using supporting documents is a warning or a fine of up to 86 fine units. There’s no separate, API-specific penalty in the law.

What should you do before 31 December 2027?

The period from 1 January 2026 to 31 December 2027 is meant for voluntary testing. Cabinet Regulation No. 749 already lets non-budget businesses submit data to VID now, without creating any obligation. Worth using that time to:

• Validate your XML invoices with the European Commission’s e-invoice validation tool before sending anything to VID.
• Test your chosen delivery channel, whether that’s the e-address, an operator or the direct API, with real transactions, not just sample data.
• Set up EDS permissions for the staff who will submit e-invoices or handle faults.
• Write down, in advance, how you’ll respond to a system fault, so the five-working-day rule doesn’t catch you out.
• Update customer master data and invoicing workflows now, because by 2028 every Latvian business client needs a structured e-invoice ready to go, not still in development.