E-invoicing APIs in Europe: what your ledger must supply

Since 1 February 2026, every VAT-registered business in Poland has had to receive its invoices through KSeF, the Ministry of Finance's clearance platform. Since 1 September 2026, every French company must be able to receive invoices through a state-registered platform. Belgium made structured invoicing between businesses compulsory on 1 January 2026. If your software creates or reads invoices for customers in these countries, each mandate needs structured invoice data and, in most of them, an e-invoicing API integration with a provider or a state platform somewhere in the chain. The five countries covered here use five different models.

Most of that work belongs to providers that sit between your product and the tax authority. What the ledger has to supply is the data: a VAT code on every line, the buyer's legal identifier and, in a growing number of countries, the invoice's status after it was sent. That part is easy to get wrong, and it repeats for every accounting system your customers use.

Five countries, five models

Belgium exchanges invoices over Peppol. The royal decree of 8 July 2025 requires the Peppol BIS format in its UBL version, sent over the Peppol network, unless both parties agree on another EN 16931 format. Exchange runs through certified service providers. A business is registered on the network at least under its enterprise number, scheme 0208, so its Peppol ID is 0208: followed by the KBO number, according to FPS Finance's Peppol FAQ. The government offers no free B2B sending tool and describes its approach as decentralised and left to the market.

Poland clears every invoice centrally. An invoice sent online counts as issued on the day it is sent to KSeF and as received on the day KSeF assigns it a number. That KSeF number has 35 characters and looks like 5265877635-20250826-0100001AF629-AF.

France routes invoices through plateformes agréées (PA), private platforms registered by the tax authority for three years at a time. The DGFiP's list, updated on 13 October 2026, has 155 platforms that passed every condition and 11 waiting on interoperability tests. Ordinary invoicing software may not send invoices to a customer's platform itself. Peppol is optional: the DGFiP became France's Peppol Authority, but a platform only has to interoperate with at least one other platform.

Germany prescribes the format and leaves the channel open. Under § 14 UStG an e-invoice follows EN 16931, or another format both sides agree on if the required data can be extracted from it. The Finance Ministry's guidance says XRechnung and ZUGFeRD from version 2.0.1 qualify, except two minimal ZUGFeRD profiles. The Finance Ministry's e-invoice FAQ says the law prescribes no particular channel, so email works as well as an API.

Spain regulates the invoicing software. Under VERI*FACTU each invoice record carries a SHA-256 hash calculated over key invoice fields and the previous record's hash, and the printed invoice shows a QR code that points to the tax agency's verification page. A separate B2B e-invoicing regime adds invoice exchange and status reporting from October 2027.

The EU sets the outer frame. Since 14 April 2025, Directive (EU) 2025/516, known as ViDA, has let member states require domestic e-invoicing without asking Brussels for a derogation. From 1 July 2030 it makes structured e-invoices the default for intra-EU B2B sales, issued within 10 days and without the buyer's consent, and a PDF no longer counts as an e-invoice. It does not oblige member states to mandate domestic B2B e-invoicing; the national rules above do that.

Receiving comes first

For a software product, the receiving dates arrive before the issuing ones. Germany has required every domestic business to be able to receive e-invoices since 1 January 2025, and the Finance Ministry says an email inbox is enough. Poland's receiving duty started for everyone on 1 February 2026, and France's on 1 September 2026. A product that reads purchase invoices from the ledger meets structured invoices before its customers have to send any.

Issuing follows in steps. In Poland, businesses with 2024 sales above PLN 200 million including VAT issue through KSeF since 1 February 2026 and everyone else since 1 April 2026, with a relief for businesses invoicing up to PLN 10,000 a month that ends on 31 December 2026. In France, large and mid-size companies issue from 1 September 2026 and small and micro companies from 1 September 2027, with e-reporting on the same calendar. German businesses with prior-year turnover above EUR 800,000 must issue e-invoices from 1 January 2027, and the transition for everyone else ends on 31 December 2027 under § 27 UStG.

Poland: building against the KSeF API

KSeF has a public REST API. The Ministry of Finance publishes the OpenAPI spec and XSD schemas on GitHub under the MIT licence, with client libraries for C# and Java. It runs three environments, from a test system to production. The test system accepts self-signed certificates and shares data between all integrators, so the docs advise using random tax numbers (NIP).

Authentication starts with POST /auth/challenge, answered with either a XAdES-signed request or a KSeF token, and returns a JWT access token and a refresh token. KSeF tokens are created after one signed login and carry fixed permissions. Tokens from KSeF 1.0, which was switched off at the end of January 2026, don't work. Invoices use the FA(3) schema, which replaced FA(2) on 1 February 2026.

Plan for KSeF being unavailable. The offline modes let a business issue an invoice offline and send it by the next business day, or within seven business days after an announced emergency mode ends. The Ministry posted disruption notices on its KSeF site on 25 September and 13 October 2026.

For the ledger, the KSeF number is the field that matters. Corrections must quote it, and from 1 January 2027 bank transfers between active VAT payers must quote it in the payment title (art. 108g of the VAT Act). On the same date, penalties of up to 100% of the VAT on an invoice issued outside KSeF start (art. 106ni), after the KSeF FAQ confirmed they were deferred to 2027. Store the number next to the invoice in the ledger, and keep the buyer's NIP on the customer record.

Spain: two regimes, and a date that may move

VERIFACTU applies to the invoicing system. In VERIFACTU mode the system sends every invoice record to the tax agency (AEAT) automatically and only needs the hash. In the other mode, records are signed with XAdES and a qualified certificate and go to the AEAT only on request. The hash covers the record's key fields, from the issuer's tax number to the invoice totals (Orden HAC/1177/2024, art. 13). Producers sign a declaration of responsibility for each version, and selling a non-compliant system can cost EUR 150,000 per financial year and per type of system under article 201 bis of the General Tax Law. The AEAT publishes the WSDL and schemas on its technical page.

The legal start dates are 1 January 2027 for corporate income tax filers and 1 July 2027 for everyone else. On 5 October 2026 the Ministry of Finance announced that it would postpone the remaining obligations to October 2028, to coincide with B2B e-invoicing for businesses with turnover up to EUR 8 million. On 17 October 2026 that change was not yet in the official journal (BOE), so the 2027 dates are still the law.

The B2B regime is separate. Orden HAC/1028/2026, published on 5 October 2026, starts it on 6 October 2027 for businesses with turnover above EUR 8 million and on 6 October 2028 for the rest, according to the AEAT calendar. Self-employed individuals start reporting invoice status and payments on 6 October 2029. Royal Decree 238/2026 allows four EN 16931 formats, among them UBL and Facturae, and private platforms must send a UBL copy of each invoice to a free public solution run by the AEAT. The buyer must tell the supplier whether it accepts or rejects the invoice, and when it paid in full, within four days, not counting weekends and national holidays, and must report the full payment date to the AEAT's public solution. An invoice the buyer does not reject is presumed accepted, and suppliers may report collection voluntarily. That makes the payment date a reporting duty on the purchase side, and it has to come from the ledger.

France: the invoice status is regulated

France regulates what happens after an invoice is sent. The external specifications v3.2 make four statuses mandatory: Déposée (deposited), Refusée (refused by the buyer), Encaissée (collected) and Rejetée (rejected by a platform check). For services where VAT is due on collection, Encaissée carries the payment date and amount. After a refusal or rejection, the supplier has to reverse the invoice in its books with an internal credit note.

Invoices also gain mandatory fields, among them the buyer's SIREN number and whether the sale covers goods or services. The 2026 Finance Act raised penalties to EUR 50 per missing e-invoice and EUR 500 per missed e-report, each capped at EUR 15,000 a year. During the start-up period, the DGFiP's practical guide says it will not apply them to companies on a serious path to compliance, and adds that this is no postponement.

Belgium and Germany

Belgium's penalties are fixed amounts, from EUR 1,500 for a first infraction up to EUR 5,000 for repeat ones, set in the same royal decree. FPS Finance said it would apply no penalties in the first three months of 2026 to businesses that had taken reasonable steps in time. E-reporting is planned for 2028 but, as the FPS FAQ puts it, still has to be written into Belgian law.

In Germany, a file with format errors does not count as an e-invoice, according to the Finance Ministry's letter of 15 October 2025, which advises keeping the validation report. Invoices must be kept for eight years under § 14b UStG.

The ledger side of an e-invoicing API integration

None of these regimes asks the ledger to handle Peppol or KSeF itself. That leg belongs to certified providers, state platform clients and compliant invoicing software. Billit, a Belgian invoicing platform, is one example: it appears on the OpenPeppol list as a certified access point and SMP provider, and it publishes a public API with OAuth 2.0 and a sandbox.

A provider can only send what the ledger gives it. Every invoice line needs a VAT rate and category the target format accepts, whether that is an EN 16931 category for Peppol BIS or a rate code from the Polish FA(3) list. The customer record needs the buyer's legal identifier, such as the enterprise number behind a Belgian Peppol ID or the NIP in Poland. The invoice needs a place for what comes back from the network, such as the KSeF number or the French platform status, and the payment events that France and Spain want reported.

Apideck's Accounting API reads and writes those objects in the customer's ledger: invoices with a tax rate per line and customers with a tax number. It also reads the ledger's own tax rates, and attachments let you keep a PDF or XML copy next to the ledger invoice. There is no dedicated field for a Peppol participant ID or a KSeF number, so those go into custom fields or pass-through, depending on the ledger. Apideck does not send or receive e-invoices and has no access point; the network leg stays with your provider.

Start with the data

If you sell into more than one of these countries, start with the data, since it is the part every mandate shares. Put correct VAT categories and buyer identifiers into every ledger you integrate with, add storage for the network reference, and choose a provider per country for the sending. The ledger side multiplies with each accounting system your customers run, the same fragmentation we described for Nordic accounting software, which is why a unified API helps there. Open Banking Tracker keeps an overview of e-invoicing regulations and a directory of Peppol providers for the country side. For the ledger side, build once against Apideck's Accounting API.