The dates

Scope: invoices to businesses and professionals established in Spain. Simplified invoices are out unless they are qualified simplified invoices.

Formats

• EN 16931 in UBL, CII, EDIFACT or Facturae. Peppol BIS is accepted on private platforms.
• The AEAT's public solution uses UBL only, with Spanish fields (copy indicator, payment date, withholdings, VERI*FACTU / TicketBAI QR reference) and no embedded files.
• Invoices through private platforms need an advanced electronic signature.
• Each invoice has a unique code: issuer NIF + series and number + issue date.

The faithful copy

If an invoice does not go through the public solution, the system that issues it must send the AEAT a faithful copy in UBL at the moment of issue, flagged with cbc:CopyIndicator = true. The AEAT validates it; a rejected copy must be fixed and resent, and duplicates are rejected.

Status and payment reporting

Buyers report acceptance or rejection and full payment (with dates) to the issuer, and full payment or rejection plus the due date to the AEAT, within four days excluding weekends and national holidays. No rejection means the invoice is presumed accepted.

VERI*FACTU

Separate regime. Legal dates are 1 January 2027 (corporate taxpayers) and 1 July 2027 (others); on 5 October 2026 the Ministry of Finance announced a move to October 2028, which still needs a new legal text.

Checklist for builders

• Segment users by the EUR 8 million threshold.
• Emit EN 16931 UBL (it is what the AEAT and the copy use).
• Decide: integrate the AEAT public solution yourself or connect a private platform.
• Add Spanish fields: copy indicator, IRPF withholdings, corrective-invoice codes, VERI*FACTU / TicketBAI reference.
• Enforce unique invoice numbers per series before anything reaches the AEAT.
• PDF companion for large issuers in year one.
• Record and report acceptance, rejection and payment within four working days.
• Validate against EN 16931 before sending.

Try it with an API

Disclosure: I build W System, the API used here. POST https://api.wsystem.dev/einvoice/create with "format": "peppol-bis3" and Spanish parties returns an EN 16931 UBL invoice checked against EN 16931. It does not add the Spanish BT-ES fields, sign, or send anything to the AEAT; use it to test your EN 16931 output, or drop a file into the free validator at wsystem.dev/e-invoice-validator. Full article with sources (BOE texts) and the live response: https://wsystem.dev/spain-b2b-e-invoicing-2027-software

Not tax advice.

The rules in one table

Until 2030 the issue duty applies in practice only when the buyer can receive, typically because it is registered in ELMA / Peppol (Skatteetaten, 29 September 2026).

Exemptions

• Turnover up to NOK 50,000 a year, for businesses that only file an income tax return: no duty to receive, and issue only if their invoicing system can. Not for accounting-obligated businesses or VAT filers.
• Bankruptcy estates, and specific rules for finance, insurance and pension companies.
• Sales to consumers are outside the B2B duty.

Peppol addressing

Norwegian companies are addressed as 0192 + the bare nine-digit organisation number (e.g. 0192:923609016). The VAT number on the invoice is NO923609016MVA, but the endpoint is the organisation number. AS, ASA and NUF sellers should also show "Foretaksregisteret" (Peppol rule NO-R-002).

Checklist for builders

• Emit EHF / Peppol BIS Billing 3.0, or connect an access point that does.
• Look up Norwegian business customers on Peppol before sending a PDF.
• Store every customer's organisation number now (mandatory on invoices from 2028, and it is the Peppol address).
• Keep the e-invoice XML in its original format.
• Plan inbound e-invoices for 2030.
• Track any EDIFACT / other-format agreements; they must end by 31 December 2029.

Try it with an API

Disclosure: I build W System, the API used here. POST https://api.wsystem.dev/einvoice/create with "format": "peppol-bis3" and Norwegian parties returns a Peppol BIS 3 UBL invoice with 0192 endpoints derived from the organisation numbers, checked against EN 16931 (Peppol-specific rules are not run yet, and nothing is sent). GET /einvoice/route?id=NO923609016MVA checks the public Peppol Directory and returns the Norwegian rules. Free for 20 calls a day; the full article with a live example and sources (Lovdata, regjeringen.no, Skatteetaten) is at https://wsystem.dev/norway-e-invoicing-2027-software.

What changed on 20 October 2026

The Council of Ministers adopted the draft VAT amendment known as UD477. It moves fines for not using KSeF (or using it wrongly) from 1 January 2027 to 1 January 2028. KSeF itself stays mandatory: in 2027 the tax administration will first remind a business individually and then check its VAT if it doesn't react. The bill still has to pass the Sejm and the Senate and be signed; it is meant to enter into force on 31 December 2026. Until it is published, plan as if the current dates apply.

Timeline

What a KSeF invoice is

• The FA(3) structure, a Polish XML schema. It is not UBL, CII or Peppol BIS.
• It counts as issued on the day it is sent to KSeF. KSeF returns a KSeF number in the official receipt (UPO); it is not in the XML and differs from your own invoice number (field P_2).
• Delivered through KSeF to Polish business buyers. Foreign buyers without a Polish establishment and consumers get it in an agreed way (for example a PDF) with a QR code and the KSeF number.

Checklist before 1 January 2027

• Drop the PLN 10,000 logic. Every B2B invoice now goes through KSeF.
• POS and shop systems: cash-register invoices and receipts with a NIP stop counting as invoices. Issue business invoices for register sales in KSeF.
• Store the KSeF number per invoice from the UPO and pass it to accounting and payments.
• Payment files: put the KSeF number (or a KSeF collective identifier for several invoices) in the transfer title, also in split-payment (MPP) messages, when both sides are active VAT payers; the payee's status comes from the official VAT white list on the payment day.
• Offline modes: offline24 lets you issue outside KSeF and send by the next business day; an offline invoice handed over outside KSeF needs two QR codes (OFFLINE and CERTYFIKAT), and the second needs a KSeF certificate obtained in advance.
• Foreign buyers: still issue in KSeF, then send a PDF with the KSeF QR code and number.
• Receiving: every Polish business has had to receive in KSeF since 1 February 2026.

Fines once they apply

Art. 106ni of the VAT Act: up to 100% of the VAT on an invoice issued outside KSeF against the rules, or up to 18.7% of the total when the invoice shows no VAT. Not tax advice.

Routing check in a multi-country app

Disclosure: I work on W System, which makes this API. W System does not submit to KSeF and does not create or validate FA(3). In a multi-country invoicing app, GET https://api.wsystem.dev/einvoice/route?id=PL7740001454 checks the buyer's VAT number in VIES, looks it up in the Peppol Directory and returns the country's mandate, so your app knows a Polish buyer needs KSeF FA(3) while a Belgian one needs Peppol BIS 3. Free for 20 calls a day per IP.

The full version with sources, FAQ and the live response is at https://wsystem.dev/poland-ksef-2027-invoicing-software.

Where France stands

The reform went live on 1 September 2026: every VAT-registered business in France must be able to receive e-invoices through an approved platform (plateforme agréée), and large companies and mid-caps (ETI) must issue them and send e-reporting data.

At the first follow-up committee on 8 October 2026 the government gave these figures as of 4 October: 75% of businesses filing VAT had chosen a receiving platform, and more than 20 million invoices worth over EUR 70 billion had been exchanged. Business organisations raised the cost and readability of platform offers, switching platforms, adapting software and the needs of the smallest firms. Large companies pointed to interoperability problems between some solutions and to lifecycle statuses not being passed on correctly. The minister confirmed that no business will be fined before the end of 2026, and the starting guide is being updated.

Timeline

What a French e-invoice has to be

• A structured format: UBL, CII, or Factur-X (structured data plus a readable image). The common minimum every platform supports is AFNOR XP Z12-012; platform APIs are XP Z12-013, B2B use cases XP Z12-014.
• Sent through an approved platform. A PDF by e-mail is not an e-invoice under the reform.
• Four new mentions: the client's SIREN (when the client is a business), the delivery address if different, the nature of the operations (goods, services or both), and "Option pour le paiement de la taxe d'après les débits" when the supplier opted to pay VAT on debits.

Rejected is not refused

The official starting guide separates the cases your software has to handle:

• Rejected by a platform: format error, missing or inconsistent mandatory data, wrong party, routing problem. Fix the file and send it again electronically; keep the file, the message, the cause and the correction.
• Refused by the buyer: a lifecycle status that must give a reason and may only be used for the reasons the standard allows, not for a commercial dispute. If you re-issue, use a new invoice number.
• Recipient not found in the directory: check SIREN, SIRET, establishment and name, then ask your platform, then the client. An e-mailed copy is a continuity measure, not a new invoice.
• Duplicates: re-sending must never cause double payment, booking or VAT deduction; mark copies and link them to the original.

Penalties (2026 finance law)

• EUR 50 per invoice not issued electronically, at most EUR 15,000 a year.
• EUR 500 per missing e-reporting transmission, at most EUR 15,000 a year per type.
• No receiving platform: formal notice, then EUR 500 after three months and EUR 1,000 for each further three months.
• A first offence fixed spontaneously or within 30 days of a request is not fined.

Checklist before 1 September 2027

1. Connect to at least one approved platform's API for issuing and receiving; let customers switch platform without re-keying.
2. Store the client's SIREN (and SIRET where used) and put supplier and client SIREN in the invoice's legal registration identifiers (BT-30 / BT-47, scheme 0002); check the field against your platform's XP Z12-012 profile.
3. Add the four new mentions, including a separate delivery address and a goods/services/both flag.
4. Make line description, quantity and unit price mandatory.
5. Validate against EN 16931 before sending, then your platform's XP Z12-012 rules; show the rule and the field, not just "rejected".
6. Store and show lifecycle statuses; re-send after a rejection, new number after a refusal.
7. Prevent duplicates and keep the evidence the guide asks for.

Catching a missing client SIREN before the platform does

Disclosure: I build W System, an EU e-invoicing and counterparty-check API. It is not an approved French platform and does not transmit invoices in France. What it does help with here: validating your UBL, CII and Factur-X files against EN 16931, and, for French parties, flagging a missing supplier or client SIREN (with a suggested value from the FR VAT number) before you hand the file to your platform. You can try it in the free in-browser validator at wsystem.dev/e-invoice-validator. The full article, with a live API response and all official sources, is on wsystem.dev.

Not tax advice; re-check the official guide before you release.

The short version

From 2 November 2026 the remaining Greek businesses (2023 gross revenue up to EUR 1 million) must issue electronic invoices for domestic B2B wholesale, B2B wholesale to non-EU countries and B2G (joint decision A.1128/2025 as amended by A.1197/2026, published 30 September 2026). Businesses above EUR 1 million have been in since 2 March 2026. Until 31 January 2027 a declared ERP or special-form path can still run in parallel; from 1 February 2027 only an AADE-licensed provider or AADE's free timologio / myDATAapp may issue in-scope invoices.

Timeline

• 2 Mar 2026: first period (gross revenue over EUR 1m) mandatory; recipients must accept domestic B2B and B2G e-invoices.
• 30 Sep 2026: A.1197/2026 moves the second-period start from 1 October to 2 November 2026.
• 2 Nov 2026: second period starts. The start declaration (provider or timologio) must give a start date no later than 2 November.
• 2 Nov 2026 – 31 Jan 2027: gradual fulfilment; ERP or the myDATA special entry form may still be used in parallel.
• 1 Feb 2027: licensed provider or AADE timologio / myDATAapp only.

What changes for software

• Scope: domestic wholesale B2B, non-EU wholesale B2B (not retail), and B2G. Retail B2C and intra-EU B2B are outside this decision.
• Issue channel: an AADE-licensed Electronic Tax Document Issuance Provider, or timologio. AADE's FAQ says plainly that ordinary business software (commercial / accounting, ERP) is not an accepted way to issue the e-invoice.
• Transmission: providers post myDATA XML (InvoicesDoc) to the myDATA API and get back a MARK (unique registration number); keep it with the invoice.
• Recipient download: since myDATA v1.0.12 provider invoices carry downloadingInvoiceUrl; recipients can fetch /pdf, /myDATA or /EN16931. Use that URL for the printed QR code.
• Penalties: not issuing an electronic invoice counts as not issuing an invoice (Tax Procedure Code).

Checklist before 2 November 2026

1. Flag each customer and transaction as in or out of scope.
2. Integrate at least one licensed provider API, or a clean hand-off to timologio for the smallest users.
3. Support the start declaration with a start date on or before 2 November 2026.
4. Store MARK, uid, authenticationCode and the QR URL on every transmitted invoice.
5. Offer the EN 16931 download for EU buyers who need the European standard, and validate EN 16931 files you generate.
6. Accept inbound e-invoices for domestic B2B and B2G.
7. Block "PDF only" for in-scope invoices after the user's obligation date.

Checking the EN 16931 side

Disclosure: I build W System, an EU e-invoicing and counterparty-check API. It is not a Greek licensed provider and does not transmit to myDATA. What it does help with here: creating and validating the EN 16931 representation (the same European standard behind /EN16931), checking Greek VAT numbers (prefix EL) in VIES before you invoice, and a free in-browser validator at wsystem.dev/e-invoice-validator. The full article, with a live API example and sources, is on wsystem.dev.

Sources

• A.1128/2025 (codified, with A.1197/2026): https://www.taxheaven.gr/circulars/51018/a-1128-2025
• A.1197/2026: https://www.taxheaven.gr/circulars/55463/a-1197-2026
• AADE FAQ (English): http://www.aade.gr/en/mandatory-electronic-invoicing-digital-goods-movement-documents-frequently-asked-questions-answers
• myDATA v1.0.12 notes: https://aade.gr/en/version-v1012

The short version

From 1 January 2027 Slovak VAT payers must send domestic B2B and B2G invoices as Peppol BIS Billing 3.0 UBL files through a certified provider (digitálny poštár), and every Slovak business must be able to receive them (Act 385/2025 Coll.). A file that passes EN 16931 can still be incomplete for Slovakia: the FR SR transposition spreadsheet v1.12 (14 October 2026) makes several optional EN 16931 fields mandatory.

Timeline

• 1 Jan 2026: Act 385/2025 in force; voluntary e-invoicing through certified providers.
• 15 Dec 2026: certified providers must have proven automated reporting.
• 1 Jan 2027: issuing e-invoices to Slovak taxable persons is mandatory; everyone must be able to receive; issue within 15 days of the supply.
• 1 Jan – 30 Jun 2027 (proposal): no fines for late e-invoices or reporting errors, and buyer-side reporting deleted. Bill 1454 passed first reading on 6 October 2026; it is not law yet.
• 1 Jul 2030: EU ViDA stage for cross-border invoices.

How an eFaktúra travels

Five-corner Peppol model without clearance: your software creates the UBL (C1), the seller's certified provider (C2) sends it to the buyer's provider (C3) and the buyer (C4), and reports tax data to the Financial Administration (C5). No QR code, hash or authority stamp. Every Slovak participant is registered in a central SMP as 0245: plus the 10-digit DIČ.

Fields Slovakia requires beyond EN 16931

• BT-34 / BT-49 (seller and buyer electronic address): mandatory, scheme 0245 + 10-digit DIČ (the digits after "SK" in the IČ DPH), not 9950 + VAT number.
• BT-35/37/38 and BT-50/52/53 (street, city, postal code): required for both parties (VAT Act s. 74(1)(a)–(b)).
• BT-30 / BT-47 (IČO): give it whenever one has been assigned.
• BT-33 (seller legal information): legal form plus the register entry (court, section, insert number).
• BT-7 (tax point date): required when the supply date is known and differs from the issue date. BT-8 is not used.
• BT-121 / BT-120 (VATEX code and reason): map every exemption to a VATEX code first, with the legal wording as text. 0 € VAT is not automatically category Z.
• BT-3: corrections are a credit note (381) plus a new invoice; type 384 is not recommended yet.

The invoice UUID

Access points identify each invoice by a UUID version 5 over "BT-34schemeID BT-34 BT-3 BT-1 BT-2" (single spaces, date as YYYY-MM-DD) with the namespace 3fd00464-9f15-52ce-8cdc-6dd374d5ad42. The worked example in the FR SR document gives the namespace itself as the output, so compute it with a standard UUIDv5 library and confirm the value with your provider.

Checklist

1. Emit Peppol BIS Billing 3.0 UBL for invoices and credit notes.
2. Store the DIČ of every Slovak party and write EndpointID schemeID="0245".
3. Make addresses mandatory for Slovak parties; store IČO and register entry; fill BT-33.
4. Fill BT-7 when the supply date differs; never send BT-8.
5. Map exemptions to VATEX codes.
6. Check whether the customer can already receive (Peppol Directory search for 0245:<DIČ>).
7. Pick a certified provider and run the Slovak tests on the Peppol Testbed.
8. Validate every outgoing file before it reaches the provider.

Try it on a sample invoice

Disclosure: I'm the maker of the API used here (W System).

POST https://api.wsystem.dev/einvoice/create turns simple JSON into a Peppol BIS 3 UBL invoice with the 0245:DIČ endpoints, checks it against the official CEN EN 16931 rules and, for Slovak sellers, adds field warnings we wrote from the v1.12 transposition (ruleset SK-FS; our reading, not the official schematron). The free browser validator at https://wsystem.dev/e-invoice-validator has a "Load a Slovak example" button. The full request and real response are in the original article.

Not tax advice; check the current FR SR transposition version before you release.

The letter in one paragraph

BMF letter of 15 October 2026 (III C 5 - S 7287-a/00019/021/017) supplements the letters of 15 October 2024 and 15 October 2025 and amends the VAT application decree (UStAE). E-invoices issued until 31 December 2026 that meet the 2024 and 2025 letters but not the new extra requirements will not be objected to, also for input VAT. Source: BMF letter (PDF).

Deadlines: unchanged

• Receiving e-invoices: mandatory since 1 January 2025.
• Issuing: from 1 January 2027 for issuers with more than EUR 800,000 prior-year turnover.
• Transition for smaller issuers (and certain EDI procedures with consent) ends 31 December 2027.

What changes for software (Rn. = paragraph in the letter)

• Final invoices (Rn. 3-4): until 30 June 2030, deduct received down payments as one sum in BT-113 (Paid amount) with the details in BT-22 (Invoice note), or in an embedded attachment referenced from the structured part.
• Down-payment invoices (Rn. 2): those issued before your obligation starts need not be e-invoices.
• Mandatory fields (Rn. 8-9): use the KoSIT / FeRD mapping of VAT-mandatory items to BT fields.
• Service description (Rn. 10-12): must be meaningful in the XML; timesheets and similar detail can be embedded attachments.
• Construction (Rn. 13-14): trades with sums in the XML plus a human-readable bill-of-quantities attachment.
• Gross-price invoices (Rn. 17-19): until 31 December 2027, totals per VAT rate in the XML and line items in an embedded attachment.
• Corrections (Rn. 20-21): must be e-invoices too; any workable correction method is fine if the result is unambiguous.
• Business-rule errors (Rn. 22-23): technically the file is not EN 16931, but for VAT it is still in principle an e-invoice unless a VAT-mandatory item is affected.
• Penalties (Rn. 28): issuing a PDF instead of a required e-invoice is not an administrative offence under § 26a(2) no. 1 UStG. It is still not compliant.

A checklist before 1 January 2027

1. Map every VAT-mandatory item to its BT/BG field.
2. Write BT-113 plus a generated BT-22 note on final invoices.
3. Always send the delivery date (BT-72) or an invoicing period.
4. Emit corrections and credit notes as e-invoices.
5. Support embedded attachments and reference them.
6. Validate every outgoing file against EN 16931 / XRechnung and report schema errors and business-rule errors separately.

Example: a final invoice with BT-113 and BT-22

Disclosure: I'm the maker of the API used here (W System).

POST https://api.wsystem.dev/einvoice/create takes simple JSON with prepaid_amount (BT-113) and note (BT-22) and returns an XRechnung checked against the official CEN EN 16931 and KoSIT XRechnung rules. Without a delivery_date it still validates but warns with BR-DE-TMP-32. The full request and the real response are on the original article. 20 free calls a day without a key.

Not tax advice; read the letter for the exact wording.

Germany has required businesses to be able to receive structured EN 16931 e-invoices since January 2025, Belgium made Peppol B2B e-invoicing mandatory in January 2026, and since September 2026 every French business must be able to receive e-invoices too. In practice that means your system will receive XRechnung XML, ZUGFeRD/Factur-X PDFs and Peppol UBL files, and before you book or send one you want to know whether it is actually valid against EN 16931, the European e-invoice standard. Here is how to check that with the official rule sets, what the results look like, and four gotchas I hit while testing today.

The official tools

Two free, open-source artefacts do the real work:

• EN 16931 validation artefacts from CEN/TC 434 (Schematron for UBL and CII, EUPL-1.2): ConnectingEurope/eInvoicing-EN16931

• KoSIT validator + XRechnung configuration (Apache-2.0), maintained by the German coordination office for IT standards. The configuration bundles the EN 16931 Schematron, the XRechnung CIUS rules and the UBL 2.1 / CII D16B schemas: itplr-kosit/validator and itplr-kosit/validator-configuration-xrechnung

Running the KoSIT validator (tested)

You need Java (I used OpenJDK 21). Download the validator jar and the latest configuration release:

mkdir kosit && cd kosit
curl -LO https://github.com/itplr-kosit/validator/releases/download/v1.6.3/validator-1.6.3-standalone.jar
curl -LO https://github.com/itplr-kosit/validator-configuration-xrechnung/releases/download/v2026-08-31/xrechnung-3.0.2-validator-configuration-2026-08-31.zip
unzip xrechnung-3.0.2-validator-configuration-2026-08-31.zip -d conf
cd conf
java -jar ../validator-1.6.3-standalone.jar -s scenarios.xml -r ${PWD} -h invoice.xml

-s points at the scenario file (it detects UBL Invoice, UBL CreditNote, CII, XRechnung and so on), -r is the repository folder with the schemas and Schematron, and -h also writes an HTML report next to the XML report (invoice-report.html, invoice-report.xml).

I ran it on two XRechnung 3.0 UBL invoices: a correct one, and a copy where I removed the Buyer reference and changed the payable amount from 1164.25 to 1164.00. The output (trimmed):

|File      |Schema |Schematron|Acceptance|Error/Description
|bad.xml   |   Y   |    N     |  REJECT  |[BR-CO-16]-Amount due for payment (BT-115) = Invoice total amount
|          |       |          |          | with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).;
|          |       |          |          |[BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden.
|good.xml  |   Y   |    N     |ACCEPTABLE|[BR-DE-TMP-32] Eine Rechnung sollte zur Angabe des Liefer-/Leistungsdatums
|          |       |          |          | entweder BT-72 "Actual delivery date", BG-14 "Invoicing period" ...
Acceptable:  1  Rejected:  1

Gotcha 1: "Schematron N" does not mean rejected

Look at good.xml above: the Schematron column says N, yet the verdict is ACCEPTABLE. The column flags any Schematron finding, including warnings. BR-DE-TMP-32 is a warning (no delivery date or invoicing period). Decide on the Acceptance column, or on the flag="fatal" entries in the XML report, not on the Schematron column.

Gotcha 2: XRechnung is stricter than EN 16931

BR-DE-15 is not an EN 16931 rule, it's an XRechnung rule: German public-sector buyers need the Buyer reference (BT-10), usually the Leitweg-ID. A file can pass plain EN 16931 and still be rejected as XRechnung. The rules that apply are chosen by the CustomizationID in the invoice (for XRechnung 3.0: urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0), so check which one your generator writes.

Gotcha 3: the totals must add up exactly

BR-CO-16 checks that amount due = total with VAT − paid amount + rounding amount. Generators that round each line differently from the document total trip this rule (and its neighbours BR-CO-10 to BR-CO-15). Compute totals from the same rounded line net amounts that you write into the file.

Gotcha 4: ZUGFeRD/Factur-X PDFs need the XML pulled out first

The KoSIT validator reads XML. A ZUGFeRD or Factur-X invoice is a PDF/A-3 with the CII XML embedded as a file attachment, usually named factur-x.xml (ZUGFeRD 2.1+ and Factur-X), zugferd-invoice.xml (ZUGFeRD 2.0) or xrechnung.xml (XRechnung profile). With pypdf:

from pypdf import PdfReader

reader = PdfReader("EN16931_Einfach.pdf")
for name, contents in reader.attachments.items():
    print(name, len(contents[0]), "bytes")
    if name.lower() in ("factur-x.xml", "zugferd-invoice.xml", "xrechnung.xml"):
        open("invoice.xml", "wb").write(contents[0])

On the official ZUGFeRD 2.3 sample EN16931_Einfach.pdf this prints factur-x.xml 13397 bytes, and the extracted file validates as ACCEPTABLE. Note that this only validates the XML; it does not check that the PDF is valid PDF/A-3 or that the visible PDF matches the XML.

Other practical tips

• Pin the configuration version. KoSIT publishes new configuration releases a few times a year as rules change; log which release you validated against so a rejection months later can be reproduced.

• Peppol BIS Billing 3.0 has its own extra rules (PEPPOL-EN16931-*) on top of EN 16931. If you send over Peppol, also run OpenPeppol's rules, which are published separately under their own terms.

• Validate what you send, not just what you receive. Most rejections I've seen come from the sender's own generator (missing BT-10, wrong unit codes, rounding).

If you'd rather not run Java and keep the rules updated

Disclosure: I'm the maker of the hosted validator below (W System).

I built a hosted version as part of the W System EU business data API. It runs the same official EN 16931 and KoSIT XRechnung artefacts (unmodified, sources linked in every response) and accepts UBL, CII or a ZUGFeRD/Factur-X PDF directly:

curl -X POST https://api.wsystem.dev/einvoice/validate \
  -H 'Content-Type: application/xml' --data-binary @bad.xml

For the broken invoice above it returns the same two errors as the KoSIT run, as JSON (trimmed):

{
  "valid": false,
  "error_count": 2,
  "warning_count": 1,
  "syntax": "ubl",
  "profile": "XRechnung",
  "errors": [
    {"rule_id": "BR-CO-16", "ruleset": "EN16931", "severity": "error",
     "business_terms": ["BT-112", "BT-113", "BT-114", "BT-115"]},
    {"rule_id": "BR-DE-15", "ruleset": "XRechnung", "severity": "error",
     "business_terms": ["BT-10"]}
  ],
  "checked": {"xsd": true, "EN16931": true, "XRechnung": true, "PeppolBIS3": false},
  "rule_versions": {"EN16931": "1.3.15+ via KoSIT config", "XRechnung": "3.0.2 config 2026-08-31"}
}

A PDF works the same way with -H 'Content-Type: application/pdf' --data-binary @invoice.pdf. Two related calls: POST /einvoice/create builds a valid XRechnung or Peppol BIS UBL invoice from plain JSON (try GET /einvoice/sample for the input format), and GET /einvoice/route?id=BE0403170701 tells you whether a company is on Peppol and what its country's e-invoicing mandate requires.

Honest limits: Peppol BIS 3 specific rules are not checked yet (the response says PeppolBIS3: false), and a technically valid file is not tax advice.

Pricing: 20 free calls per day per IP with no API key or signup. After that, x402 pay-per-call in USDC on Base ($0.03 per validation, $0.08 per created invoice, $0.02 per route lookup), or a monthly plan with an API key (Starter €19/month for 5,000 units, Pro €49/month for 25,000 units; a validation uses 3 units). It's also available to AI agents as MCP tools (validate_einvoice, create_einvoice, einvoice_route) on the remote MCP server at https://api.wsystem.dev/mcp/.

Details and docs: EU e-invoice validation API.

If you import into or export out of the EU, every customs declaration carries an EORI number (Economic Operators Registration and Identification). Freight forwarders, customs brokers and marketplaces check these numbers when onboarding a shipper, and a typo or a deregistered number means a held shipment. The European Commission runs a free validation service called EOS. It has a web form, but for anything automated you'll want its SOAP API. Here is what works today, including two gotchas that cost me time.

The endpoint

POST https://ec.europa.eu/taxation_customs/dds2/eos/validation/services/validation
Content-Type: text/xml; charset=utf-8

No API key, no account. One request can carry up to 10 EORI numbers.

curl -s -X POST https://ec.europa.eu/taxation_customs/dds2/eos/validation/services/validation \
  -H 'Content-Type: text/xml; charset=utf-8' \
  -d '<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ev:validateEORI xmlns:ev="http://eori.ws.eos.dds.s/">
      <ev:eori>SE5560360793</ev:eori>
      <ev:eori>DE1234567</ev:eori>
    </ev:validateEORI>
  </soap:Body>
</soap:Envelope>'

The response I got back today (trimmed):

<return>
  <requestDate>17/10/2026</requestDate>
  <result>
    <eori>SE5560360793</eori><status>0</status><statusDescr>Valid</statusDescr>
    <name>SAAB Aktiebolag</name><postalCode>58188</postalCode>
    <city>LINKÖPING</city><country>Sweden</country>
  </result>
  <result>
    <eori>DE1234567</eori><status>1</status><statusDescr>Not valid</statusDescr>
  </result>
</return>

• status 0 = valid, 1 = not valid.

• Name and address only appear when the trader agreed to publish them. Many valid numbers come back with no name at all, so don't treat a missing name as a failure.

• requestDate is the date of the check. Store it alongside the result if you need an audit trail.

A Python version (tested)

import re
import xml.etree.ElementTree as ET
import requests

EOS_URL = "https://ec.europa.eu/taxation_customs/dds2/eos/validation/services/validation"
NS = "http://eori.ws.eos.dds.s/"

def clean(eori: str) -> str:
    return re.sub(r"[\s.\-]", "", eori).upper()

def check_eoris(eoris):
    """Validate up to 10 EU EORI numbers per call against the EC EOS service."""
    eoris = [clean(e) for e in eoris]
    body = "".join(f"<ev:eori>{e}</ev:eori>" for e in eoris)
    envelope = (
        '<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">'
        f'<soap:Body><ev:validateEORI xmlns:ev="{NS}">{body}</ev:validateEORI>'
        "</soap:Body></soap:Envelope>"
    )
    r = requests.post(EOS_URL, data=envelope.encode(),
                      headers={"Content-Type": "text/xml; charset=utf-8",
                               "User-Agent": "my-app-eori-check/1.0"},  # see gotcha below
                      timeout=20)
    r.raise_for_status()
    out = []
    for res in ET.fromstring(r.content).iter("result"):
        item = {child.tag: child.text for child in res}
        item["valid"] = item.get("status") == "0"
        out.append(item)
    return out

if __name__ == "__main__":
    for row in check_eoris(["SE 556036-0793", "DE1234567"]):
        print(row)

Output:

{'eori': 'SE5560360793', 'status': '0', 'statusDescr': 'Valid', 'name': 'SAAB Aktiebolag', ..., 'city': 'LINKÖPING', 'country': 'Sweden', 'valid': True}
{'eori': 'DE1234567', 'status': '1', 'statusDescr': 'Not valid', 'valid': False}

For more than 10 numbers, chunk the list into groups of 10 and send the chunks with modest concurrency.

Gotcha 1: the default python-requests User-Agent gets a 502

This one surprised me. The exact same envelope that works with curl returned HTTP 502 Bad Gateway from Python requests every time. The only difference was the User-Agent header: with the library default (python-requests/x.y) the gateway answers 502, and with any other value, like my-app-eori-check/1.0, it answers 200. So if you see 502s from EOS in code but not in your terminal, set a User-Agent before you start debugging the XML.

Gotcha 2: GB numbers aren't in EOS any more

Since Brexit, GB... EORIs are validated by HMRC, not the Commission. Northern Ireland traders have an XI... number, which is in EOS. HMRC's API is a simple JSON call, also without auth:

curl -s -X POST https://api.service.hmrc.gov.uk/customs/eori/lookup/check-multiple-eori \
  -H 'Content-Type: application/json' \
  -H 'Accept: application/vnd.hmrc.1.0+json' \
  -d '{"eoris":["GB225109100000"]}'

A robust checker routes by prefix: GB goes to HMRC, everything else (EU-27 plus XI) goes to EOS.

Other practical tips

• Clean the input. People paste SE 556036-0793 or de-123.456. Strip spaces, dots and dashes and uppercase it before sending.

• Validate the format locally. An EORI is a two-letter country code followed by up to 15 alphanumeric characters (17 in total at most). Rejecting garbage locally saves calls and gives users instant feedback.

• An outage is not "invalid". EOS has maintenance windows and occasional 5xx errors. Retry with backoff and mark the check as pending, so a customer isn't rejected because Brussels was down.

• EORI is not VAT. In many EU countries the EORI is based on the company's VAT or tax number, but it's a separate registration: a valid VAT number doesn't mean the company has an EORI, and vice versa. Check VAT numbers against VIES separately.

If you'd rather not maintain the SOAP plumbing

Disclosure: I'm the maker of the EORI checker below (W System).

I built two hosted versions of the above, with the input cleaning, format checks, chunking and retries done for you:

• Apify Actor: EU EORI Number Checker. Batch up to 1,000 EORIs per run, JSON or CSV out, $0.01 per answered check plus $0.005 per run. Format errors and EOS outages aren't charged. It also works as a tool for AI agents through Apify's MCP server (https://mcp.apify.com/?tools=wsystem/eu-eori-checker).

• HTTP API / MCP server: GET https://api.wsystem.dev/eori?eori=SE5560360793 and POST /eori/batch, plus a remote MCP endpoint at https://api.wsystem.dev/mcp/ with a verify_eori tool. 20 free calls per day per IP, then pay per call in USDC via x402. Source on GitHub.

Either way, the official endpoint above is free and works fine if you'd rather run it yourself.

If you onboard customers, suppliers or payees, you need to check them against sanctions lists. The official sources are free: the EU Financial Sanctions consolidated list, the UN Security Council list, OFAC SDN and the UK sanctions list. They come in four different formats, get updated constantly, and the names are spelled inconsistently (transliterations, aliases, word order).

What good screening needs

• All relevant lists. EU businesses usually need at least EU + UN; anyone touching USD needs OFAC too.

• Fuzzy matching. "Sberbank" vs "Sberbank of Russia", Cyrillic vs Latin transliteration.

• Scores, not yes/no. A human should review hits above a threshold.

• Disambiguators. Birth year and country cut down false positives a lot.

• Fresh data. Lists change weekly, sometimes daily.

One call

Disclosure: I'm the maker of this Actor (W System).

The Sanctions Screening Actor refreshes all four lists daily and returns scored matches. $0.005 per screened name.

{
  "names": ["Vladimir Putin", "Sberbank", "Example Trading Ltd"],
  "threshold": 85,
  "birthYear": null,
  "country": null,
  "maxMatchesPerName": 5
}

from apify_client import ApifyClient
client = ApifyClient("<APIFY_TOKEN>")
run = client.actor("wsystem/sanctions-screening").call(run_input={"names": ["Sberbank"], "threshold": 85})
for hit in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(hit)

AI agents can also reach our tools through the hosted API at https://eu-vat-checker.onrender.com (20 free calls/day, then x402 USDC pay-per-call; MCP endpoint at /mcp/).

Caveats

• Screening is a signal, not a legal decision. Document how you review hits.

• Tune threshold: 85 is a reasonable start, but go lower for high-risk flows.

• Re-screen your existing customer base when lists update, not just at onboarding.

Disclosure: I'm the maker of these Actors (W System).

Four Apify Actors: Sanctions Screening, EU VAT Checker, European Company Registry, EU Tenders Search. Here's how to call them from common tools.

Claude Desktop / Cursor / any MCP client

Apify hosts an MCP server that exposes Actors as tools:

{
  "mcpServers": {
    "apify": {
      "command": "npx",
      "args": ["-y", "@apify/actors-mcp-server", "--actors", "wsystem/eu-vat-checker,wsystem/european-company-registry,wsystem/eu-tenders-search,wsystem/sanctions-screening"],
      "env": { "APIFY_TOKEN": "<your token>" }
    }
  }
}

Alternatively, use Apify's hosted server at https://mcp.apify.com (OAuth, no local install). Then ask: "Check whether HU12345678 is a valid VAT number and give me the consultation number."

There is also our own hosted HTTP API at https://eu-vat-checker.onrender.com with an MCP endpoint at https://eu-vat-checker.onrender.com/mcp/: 20 free calls/day, then agents pay per call in USDC via x402 (no account needed).

n8n

Use the Apify node (or HTTP Request) → Run Actor and get dataset items: POST https://api.apify.com/v2/acts/wsystem~eu-vat-checker/run-sync-get-dataset-items?token=<TOKEN> with the JSON input as body. Typical flow: new invoice in Sheets → VAT check → write status back.

Make

Apify app → "Run an Actor" (synchronous) → "Get Dataset Items". Same input JSON.

LangChain (Python)

from langchain_apify import ApifyActorsTool
vat = ApifyActorsTool("wsystem/eu-vat-checker")
tenders = ApifyActorsTool("wsystem/eu-tenders-search")  # needs APIFY_API_TOKEN env var
# pass [vat, tenders] to your agent's tools

Pricing is pay-per-result (\(0.01 / VAT check, \)0.008 / company lookup, $0.003 / tender notice), so agents only cost money when they get answers.

KYB checks, CRM enrichment and invoice validation all need the same thing: is this company real, active, and what's its official address? Europe has no single register, but many national registers now offer free open data:

Each has its own API, auth, rate limits and field names. Normalising them is the real work.

One interface

Disclosure: I'm the maker of this Actor (W System).

The European Company Registry Lookup Actor queries these registers (plus GLEIF LEI for any country) and returns a common schema: name, ID, status, address, VAT ID, NACE code. Batch input, $0.008 per lookup.

Input is a list of COUNTRY:id-or-name queries:

{"queries": ["FR:552032534", "NO:equinor", "CZ:skoda auto"], "maxResultsPerQuery": 3}

Practical advice

• Search by ID when you have it; name search is fuzzy and returns several candidates.

• Always check status (active / dissolved / in liquidation) and not just existence.

• Combine with a VIES VAT check for cross-border invoicing (see EU VAT Checker).

• Coverage is limited to the registers listed; for Germany/others GLEIF LEI is the fallback, and only covers companies with an LEI.

Every above-threshold public contract in the EU is published on TED (Tenders Electronic Daily), roughly thousands of notices per week. If you sell to the public sector, a daily filtered feed beats manual searching.

1. Pick your filters

• CPV codes: the EU procurement taxonomy. E.g. 72000000 (IT services), 48000000 (software), 79400000 (consulting). Use the top-level code to catch children.

• Countries: ISO codes of buyers you can serve.

• Keywords: in multiple languages: notices are often only in the local language ("software", "Software", "logiciel", "szoftver").

• Deadline: skip notices closing in < 7 days.

2. Official route

TED offers a public search API (https://api.ted.europa.eu/v3/notices/search) with an expert query syntax. It works, but you'll handle pagination, the query language and field mapping yourself.

3. Shortcut: a scheduled Actor

Disclosure: I'm the maker of this Actor (W System).

The EU Public Tenders Search Actor takes keywords, CPV codes, countries and deadline filters and returns clean JSON, with a "new notices only" monitoring mode. $0.003 per notice returned.

Set it up daily:

1. Open the Actor, fill in filters and set onlyNew: true, then save it as a Task. Example input:

{"keywords": ["software", "logiciel"], "cpvCodes": ["72000000"], "countries": ["DE", "FR"], "onlyOpen": true, "onlyNew": true, "maxNotices": 100}

1. Apify Console → Schedules → cron 0 7 * * 1-5 → attach the Task.

2. Add an integration (webhook, Slack, email, Google Sheets, n8n/Make) on "run succeeded".

4. Triage tips

• Score by value + CPV match + deadline, and only alert on top hits.

• Dedupe on notice ID (publication number).

• Keep a "lost/ignored" list to refine keywords monthly.

VIES (the EU's VAT Information Exchange System) is free and authoritative, but it is a gateway in front of 28 national systems (EU-27 + Northern Ireland "XI"). Individual member-state nodes regularly return MS_UNAVAILABLE, MS_MAX_CONCURRENT_REQ or time out, often during business hours.

Rule #1: "could not check" is not "invalid"

Treat these as transient, never as a negative result:

• MS_UNAVAILABLE, SERVICE_UNAVAILABLE, TIMEOUT, MS_MAX_CONCURRENT_REQ, GLOBAL_MAX_CONCURRENT_REQ, HTTP 5xx. Retry with exponential backoff (e.g. 2s, 8s, 30s, then requeue for minutes later). Don't block checkout; apply VAT provisionally or flag the order for review.

Rule #2: keep the consultation number

If you send your own VAT number as the requester, VIES returns a consultation number (requestIdentifier). Tax authorities accept it as proof that you checked. Store it with the timestamp and raw response.

Doing it with the official REST API

curl -s -X POST https://ec.europa.eu/taxation_customs/vies/rest-api/check-vat-number \
  -H 'Content-Type: application/json' \
  -d '{"countryCode":"DE","vatNumber":"123456789","requesterMemberStateCode":"HU","requesterNumber":"12345678"}'

Check member-state availability first: GET https://ec.europa.eu/taxation_customs/vies/rest-api/check-status.

Batch + retries without writing the plumbing

Disclosure: I'm the maker of this Actor (W System).

If you'd rather not maintain retry queues, the EU VAT Number Checker Actor on Apify wraps VIES with automatic retries on outages, batch input, company name/address and the consultation number. It costs $0.01 per answered check (you aren't charged for checks VIES couldn't answer).

from apify_client import ApifyClient
client = ApifyClient("<APIFY_TOKEN>")
run = client.actor("wsystem/eu-vat-checker").call(run_input={
    "vatNumbers": ["DE123456789", "HU12345678"],
    "requesterVatNumber": "HU12345678",  # your own VAT no. -> consultation number
})
for item in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(item)

Prefer plain HTTP or an AI agent? The same check is on a hosted API at https://eu-vat-checker.onrender.com (20 free calls/day, then pay-per-call in USDC via x402; MCP endpoint at /mcp/).

Checklist

• Normalise input (strip spaces/dots, uppercase, Greece = EL not GR).

• Validate format locally before calling VIES.

• Retry transient errors; never cache them as invalid.

• Store consultation number + timestamp.

• Re-check long-term B2B customers periodically; numbers get deregistered.