How to use this glossary
Terms are grouped by market, because that is how the obligations arrive. Each heading is the term itself, so it can be matched and quoted directly. Where a term has a false friend, a common mistranslation or a deprecated predecessor, the entry says so — those sentences are the ones worth carrying into a search box.
Four cross-cutting corrections are worth stating before the list, because they recur in every market: no regulation anywhere names AI agents, and the obligations arrive through data protection, cyber and financial-services regimes that already governed whatever the agent touches; an application log is not an audit trail; re-running an agent produces a new decision rather than an explanation of the old one; and a control that reports an action is not a control over an irreversible action.
Poland — KSeF
Poland runs a central clearing model. The system has been live since 2026 and penalties under art. 106ni begin on 1 January 2027.
KSeF (Krajowy System e-Faktur)
Poland's national e-invoicing system. Issuing became mandatory on 1 February 2026 for taxpayers whose 2024 sales including tax exceeded PLN 200 million, and on 1 April 2026 for everyone else, including taxpayers exempt on subjective grounds and micro-entrepreneurs; the duty to receive applied to all taxpayers from 1 February 2026. The most persistent error in secondary sources is a micro-entrepreneur deferral: Sejm print no. 2321, tabled on 13 February 2026, stalled after its first reading on 13 March 2026 and was never passed, yet it is still cited as law in advisory material.
In depth: KSeF, automatyzacja i AI — kompletny przewodnik dla firm
faktura ustrukturyzowana
Literally 'structured invoice' — the statutory term for an invoice issued through KSeF in the mandated logical structure. It is not a synonym for e-faktura: in general usage an e-faktura is any electronic invoice, while a faktura ustrukturyzowana is specifically one that has passed through KSeF and been assigned a numer KSeF. The two phrases retrieve two different bodies of Polish material, and only one of them is about the mandate.
In depth: KSeF, automatyzacja i AI — kompletny przewodnik dla firm
numer KSeF
The identifier KSeF assigns to a structured invoice on acceptance. From 1 January 2027, art. 108g requires the numer KSeF to appear in the payment reference for a structured invoice. An invoice that has received one cannot be deleted: a duplicate created by an unguarded retry carries its own numer KSeF and can only be undone by a correcting invoice, which is why idempotency here is a documentation problem as much as an engineering one.
In depth: Duplikaty i ponawianie operacji w KSeF: dlaczego idempotencja ma znaczenie
UPO (Urzędowe Poświadczenie Odbioru)
The official confirmation of receipt returned by KSeF once an invoice is accepted. A timeout in a KSeF API call does not mean the invoice was rejected — it means you did not receive an answer, and the document may already hold a numer KSeF and a UPO. The correct response is to query status against your own reference identifier, and to re-send only on unambiguous confirmation that the document was not accepted.
In depth: Ślad audytowy w KSeF: jak udokumentować każdą automatyczną operację
FA(3)
The logical structure for structured invoices in force since 1 February 2026, published in the Centralne Repozytorium Wzorów Dokumentów. FA(2) applied from 1 September 2023 to 31 January 2026. The operational detail most implementations miss: FA(3) also governs correcting invoices issued now against original documents drawn up earlier under FA(2) or FA(1).
In depth: KSeF, automatyzacja i AI — kompletny przewodnik dla firm
tryb offline24
The offline mode a taxpayer may use at any moment on their own decision, with no outage and no justification required (art. 106nda); the invoice must reach KSeF by the end of the next working day after the date of issue. Because there is no external event to point to, it carries the greatest evidential exposure of the four modes: if the invoice arrives late, the only available explanation is whatever your own system recorded. The date of issue is the P_1 field of the logical structure — not the moment of transmission, not the ERP creation timestamp.
In depth: Tryby offline w KSeF: offline24, awaria i niedostępność systemu
awaria
A KSeF failure announced by the Ministry of Finance, opening the tryb awaryjny under art. 106nf: invoices must be transmitted within seven working days of the failure being removed — counted from removal, not from occurrence, and the longest deadline of any mode. A separate announcement covers awaria całkowita, total failure, where invoices are not transmitted to KSeF at all and carry neither QR code.
In depth: Tryby offline w KSeF: offline24, awaria i niedostępność systemu
niedostępność
Announced unavailability of KSeF under art. 106nh, and a different mode from awaria with a different deadline: transmission by the next working day after availability is restored. Both are announced in the Ministry's Biuletyn Informacji Publicznej and by a message in the system interface. A system that does not capture the state of those announcements at the moment of issue cannot afterwards demonstrate that the mode it selected was actually available to it.
In depth: Tryby offline w KSeF: offline24, awaria i niedostępność systemu
KOD I i KOD II
The two QR codes on an offline invoice, with entirely different purposes. KOD I carries the environment address, the date, the seller's NIP and a Base64URL-encoded SHA-256 digest of the XML file, and appears on every invoice visualisation including online ones. KOD II is signed with the private key of an Offline-type KSeF certificate (keyUsage Non-Repudiation) and attests the issuer's identity at a moment the system could not; it appears only on offline invoices, and the certificate that signs it is a separate issuance most organisations discover they lack in the middle of an incident.
In depth: Tryby offline w KSeF: offline24, awaria i niedostępność systemu
Germany — E-Rechnung and NIS-2
Receiving has been mandatory since 2025 and issuing arrives in 2027 and 2028. Two figures are almost always cited wrongly, and one duty in § 38 BSIG is quoted from a draft that never became law.
E-Rechnung
Under § 14 (1) UStG, an invoice in a structured electronic format that is created, transmitted and received electronically, permits electronic processing and conforms to EN 16931. Everything else — paper, PDF, TIFF, a Word file — is a sonstige Rechnung, so a PDF sent by email is not an E-Rechnung. Receiving has been mandatory for every domestic business since 1 January 2025; issuing follows on 1 January 2027 for issuers with 2026 total turnover above €800,000 and on 1 January 2028 without exception.
In depth: E-Rechnung, Automatisierung und KI — der vollständige Leitfaden
sonstige Rechnung
The German tax term for any invoice that is not an E-Rechnung, which in electronic form requires the recipient's consent. The expensive trap is that ZUGFeRD in the MINIMUM or BASIC-WL profile is a sonstige Rechnung for VAT purposes even though every validation tool accepts the file as valid ZUGFeRD — neither profile is a complete invoice within the meaning of the standard.
In depth: XRechnung und ZUGFeRD: Formate, Profile und Fallstricke
XRechnung
The purely structured German format — XML only, no PDF layer — maintained by KoSIT, with Standard XRechnung 3.0.2 currently binding. XRechnung 4.0, implementing EN 16931-1:2026, was announced for 'mid to late 2026', but no published version and no binding application date could be confirmed. Treat 4.0 as a watch point rather than a milestone, and make the standard version a configurable parameter rather than a hard-wired value.
In depth: XRechnung und ZUGFeRD: Formate, Profile und Fallstricke
ZUGFeRD
The hybrid German format published by FeRD: a PDF/A-3 file with embedded XML, current version 2.5.2, conformant from 2.0.1 with the exception of the MINIMUM and BASIC-WL profiles. In a hybrid file the structured XML part is authoritative. Where the PDF image differs in substance, that divergence can constitute a second invoice with a tax liability under § 14c UStG — which is why the XML and the image must be generated from one data source in one step, not by a reporting tool and an interface that drift apart over release cycles.
In depth: XRechnung und ZUGFeRD: Formate, Profile und Fallstricke
Empfangspflicht
The duty to be able to receive E-Rechnungen, in force since 1 January 2025 for every domestic business, with no turnover threshold, no transitional arrangement and no exemption for Kleinunternehmer; the BMF regards an email inbox as sufficient. The retention period is eight years under § 14b UStG, not ten. The ten-year figure survives in guides, training material and internal process documentation, and it produces a deletion policy dimensioned for the wrong statute.
In depth: Empfangspflicht für E-Rechnungen: was seit dem 1. Januar 2025 gilt
Leitweg-ID
A public-procurement routing attribute under the E-Rechnungsverordnung, transmitted in EN 16931 as the Buyer reference (BT-10). It concerns B2G only. Guides that require it in domestic B2B are wrong, and the practical consequence is an inbound validation rule that rejects perfectly valid invoices for a missing field. A B2B recipient may of course ask for its own reference in BT-10, such as a purchase order number, but that is a contractual arrangement rather than a statutory requirement.
In depth: XRechnung und ZUGFeRD: Formate, Profile und Fallstricke
§ 38 BSIG
The management-body duty in the German NIS-2 transposition, in force since 6 December 2025. Paragraph 1 requires management to implement the § 30 risk-management measures and to supervise their implementation — umsetzen und überwachen, not billigen. The approval duty that is quoted everywhere came from the Referentenentwurf and did not survive into the enacted law, and neither did the clause voiding a waiver of claims. Liability under paragraph 2 runs to the entity itself under the company law applicable to its legal form, with the BSIG applying only subsidiarily; it is not an external liability towards customers.
In depth: NIS-2 und § 38 BSIG: die Pflichten und die Haftung der Geschäftsleitung
France — facturation électronique
Live since 1 September 2026. One term was retired by decree on 27 July 2026, and using it dates a document immediately.
facturation électronique
The French e-invoicing reform, in force since 1 September 2026: every VAT-registered business must be able to receive, and grandes entreprises and entreprises de taille intermédiaire must also issue and transmit e-reporting data from the same date. PME, TPE and micro-entreprises follow on 1 September 2027 as a single wave — there is no separate TPE step, and that deadline covers e-reporting as well as issuing. Company size is assessed at unité légale level by SIREN and fixed as at 1 January 2025; the reference date did not move with the calendar, so crossing a threshold in 2025 or 2026 changes nothing.
In depth: Facturation électronique : ce qui a changé le 1er septembre 2026
plateforme agréée (PA)
The registered platform through which all B2B flows now pass. Décret n° 2026-677 and the arrêté of 27 July 2026, published in the Journal officiel of 28 July, replaced 'opérateur de plateforme de dématérialisation partenaire (PDP)' with 'plateforme agréée (PA)', and the tax administration has switched vocabulary including in its own page titles. PDP is obsolete: using it as a current term signals content not reviewed since the summer of 2026. Distinguish the opérateur de dématérialisation (OD), which is not registered and cannot transmit to the administration on its own.
In depth: Facturation électronique : ce qui a changé le 1er septembre 2026
portail public de facturation (PPF)
Article 123 of the 2026 finance law definitively ended the free public portal for issuing and receiving. The PPF retains exactly two functions: the annuaire central of invoice recipients (CGI art. 289 bis) and the concentrateur, the dedicated collection point for data and lifecycle statuses (CGI art. 242 nonies G). There is therefore no free public route for issuing. Chorus Pro remains the public-sector platform for B2G and is unaffected by the change.
In depth: Facturation électronique : ce qui a changé le 1er septembre 2026
Factur-X
The hybrid French format — PDF/A-3 with embedded XML — and one of the three formats socles alongside UBL and CII, all founded on EN 16931 and all equally compliant. It is technically the twin of the German ZUGFeRD and is admissible in Germany where EN 16931-conformant. Every plateforme agréée must be able to issue in all three formats socles and to receive and process all three; other formats may circulate between platforms by agreement, but the socle is what guarantees an exchange completes.
In depth: Factur-X, UBL et CII : comprendre les formats de la facturation électronique
e-reporting
Officially the transmission des données de transaction. It follows the issuing dates and never the reception dates: GE and ETI since 1 September 2026, PME, TPE and micro-entreprises from 1 September 2027. It covers operations with non-taxable persons (B2C), international operations, and payment data for services. Excluded are imports of goods, VAT-exempt activities such as health and training, operations under the OSS and IOSS schemes, and defence-classified operations.
In depth: Facturation électronique : ce qui a changé le 1er septembre 2026
piste d'audit
The durable link between what you control — the source document and the integration layer — and what the rest of the chain returns to you. Since the reform an invoice crosses your ERP, your plateforme agréée, the annuaire, the concentrateur and the recipient's platform, and you control only the first two links. Application logs do not close the gap: they rotate, they remain modifiable, and their completeness depends on a level adjusted in production. The test is to take an invoice at random from three months ago and reconstruct it without application logs and without a developer.
In depth: Comment créer une piste d'audit pour les workflows de facturation automatisés
rejetée / refusée
Two of the four mandatory lifecycle statuses, and routinely conflated. Rejetée is a technical rejection by a platform for non-conformity of format or business rules; refusée is a commercial refusal by the recipient, admitted on only three grounds, and the administration states expressly that it must not be used for an ordinary commercial dispute. A system that maps internal error codes onto these statuses is not emitting acknowledgements — it is emitting legal qualifications, so the mapping deserves an audit of its own, and the trail must retain both the internal code and the status emitted.
In depth: Comment créer une piste d'audit pour les workflows de facturation automatisés
Switzerland — LPD / DSG, and why Swiss French is not France French
Switzerland has no AI act and will not have a horizontal one; four regimes bite already. Its French-language terminology diverges from France's, and using the French forms retrieves the wrong instrument.
LPD / DSG
The Swiss Federal Act on Data Protection — loi fédérale sur la protection des données (LPD) in Swiss French, Datenschutzgesetz (DSG) in Swiss German — RS/SR 235.1, in force since 1 September 2023. It is technology-neutral, and the PFPDT/EDÖB confirmed on 8 May 2025 that it applies directly to AI-assisted processing. Swiss French says données personnelles where France French says données à caractère personnel, and Swiss German says Bearbeitung where German says Verarbeitung: a text using the French or EU forms is describing the RGPD/DSGVO, not the LPD.
In depth: Gouvernance de l'IA en Suisse : pas de loi sur l'IA, et c'est pour cela que les obligations mordent
OPDo / DSV
The data protection ordinance — ordonnance sur la protection des données (OPDo) in Swiss French, Datenschutzverordnung (DSV) in Swiss German — RS/SR 235.11. Its art. 24 exempts private organisations employing fewer than 250 people on 1 January of a year from keeping a register of processing activities. The exception to the exemption is the operative part: large-scale sensitive data or high-risk profiling reinstates the duty regardless of size, and a scoring or classification model applied to people can constitute high-risk profiling. Note that the 250-employee figure belongs to the register, not to the AIPD.
In depth: Décision individuelle automatisée : ce que l'art. 21 LPD exige des agents IA
PFPDT / EDÖB
The Federal Data Protection and Information Commissioner — Préposé fédéral à la protection des données et à la transparence in Swiss French, Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter in Swiss German. It does not impose fines. It issues decisions, and the fines under LPD/DSG arts. 60–63 are pronounced by the cantonal criminal prosecution authorities against natural persons, with disregard of a PFPDT decision itself punishable under art. 63. Where a high residual risk remains after an impact assessment, it takes a position within two months, extendable by one.
In depth: Gouvernance de l'IA en Suisse : les quatre régimes qui engagent déjà
AIPD / DSFA
The data protection impact assessment required by art. 22 LPD/DSG where processing may entail a high risk, with paragraph 2 expressly naming the use of new technologies. There is no size threshold: twelve employees deploying automated candidate screening face the same criterion as a large group. And the widely repeated 'CHF 250,000 for a missing AIPD' is wrong twice over — a missing AIPD is not in itself punishable, and the fines are criminal ones against natural persons, with the company liable only subsidiarily and only up to CHF 50,000 under art. 64 para. 2.
In depth: AIPD et intelligence artificielle : quand l'analyse d'impact est obligatoire
LSI / ISG
The Information Security Act — loi sur la sécurité de l'information (LSI) / Informationssicherheitsgesetz (ISG) — RS/SR 128, arts. 74a ff. It is the Swiss functional counterpart to NIS2, which as an EU directive does not apply in Switzerland at all. Reporting has been mandatory since 1 April 2025, with fines up to CHF 100,000 since 1 October 2025, and it binds only the authorities and organisations of art. 74b: critical infrastructure operators and public bodies. A fiduciary or an ordinary industrial company is outside its scope, while the LPD reporting duty to the PFPDT is general.
In depth: Obligation de signaler les cyberattaques : 24 heures à l'OFCS
OFCS / BACS
The Federal Office for Cybersecurity — Office fédéral de la cybersécurité / Bundesamt für Cybersicherheit — successor to the NCSC, which became a federal office on 1 January 2024. Critical infrastructure operators report a cyberattack to it within 24 hours of discovery and complete an incomplete first report within 14 days. It is not interchangeable with the PFPDT/EDÖB: two addressees, two thresholds and two clocks, and a single incident can trigger both duties.
In depth: ISG-Meldepflicht: 24 Stunden an das BACS — wen sie bindet und wen nicht
décision individuelle automatisée / automatisierte Einzelentscheidung
A decision based exclusively on automated processing that has legal effects for the person or significantly affects them (art. 21 LPD/DSG) — two cumulative conditions. Unlike art. 22 RGPD/DSGVO this is not a prohibition with exceptions but a duty to inform, plus rights to state one's position and to obtain review by a natural person. Transposing a GDPR implementation one-for-one therefore over-restricts in one place and under-specifies in another. The contract exception in para. 3 lit. a applies only where the person's request is granted, so every automated refusal remains fully in scope.
In depth: Décision individuelle automatisée : ce que l'art. 21 LPD exige des agents IA
annoncer / signaler
Two Swiss legal verbs that a France-French text collapses into one. Under the LPD you annoncer a data security breach to the PFPDT, dans les meilleurs délais and only above a high risk to the person — there is no 72-hour deadline in Swiss law and the trigger threshold is higher than the GDPR's. Under the LSI you signaler a cyberattack to the OFCS within 24 hours. Keeping the two verbs apart is what keeps the two processes, two authorities and two clocks apart in practice.
In depth: Obligation de signaler les cyberattaques : 24 heures à l'OFCS
conseiller à la protection des données
The Swiss French term for the data protection adviser (Datenschutzberaterin oder Datenschutzberater in Swiss German). Where a high residual risk survives the measures taken, art. 23 LPD requires consultation of the PFPDT — but a private controller may instead address its conseiller à la protection des données. It is one of several points where Romandie usage diverges from France's, alongside données personnelles rather than données à caractère personnel and the annoncer/signaler split, and it is the vocabulary the Swiss authorities themselves use.
In depth: AIPD et intelligence artificielle : quand l'analyse d'impact est obligatoire
Bearbeitung
Swiss German for the handling of personal data, where German and EU-German texts say Verarbeitung. The DSG uses Bearbeitung throughout: an automated individual decision is one that beruht ausschliesslich auf einer automatisierten Bearbeitung, and the art. 12 register is a Verzeichnis der Bearbeitungstätigkeiten. Swiss German also writes ss where German writes ß. A document containing Verarbeitung and ß is describing the DSGVO rather than the DSG, whatever its title says.
In depth: Automatisierte Einzelentscheidungen nach Art. 21 DSG
United Kingdom — automated decision-making after the DUAA
There is no UK AI Act and none is before Parliament. The live obligations came from data protection law on 5 February 2026.
DUAA 2025 (Data (Use and Access) Act 2025)
The Data (Use and Access) Act 2025 (c. 18). Section 80 substituted UK GDPR Article 22 with a new Section 4A containing Articles 22A to 22D, commenced on 5 February 2026 by SI 2026/82. The change is prospective: regulation 5 saves decisions taken before that date under the old Article 22(3), so a system running since 2024 sits across two legal regimes and any audit of historic decisions has to respect that line.
In depth: Automated decision-making after the DUAA: what changed on 5 February 2026
UK GDPR Articles 22A–22D
Article 22 no longer exists. 22A defines the scope, 22B restricts decisions involving special category data, 22C sets the safeguards — information about the decision, the ability to make representations, human intervention and a right to contest — and 22D grants Secretary of State regulation-making powers. For decisions not involving special category data the old general prohibition becomes permission-plus-safeguards, so any lawful basis including legitimate interests will do. The ICO's 2023 AI guidance still carries a March 2023 date, is under review and does not state the current law; the defensible citation is the statute.
In depth: Automated decision-making after the DUAA: what changed on 5 February 2026
meaningful human involvement
The phrase in Article 22A that decides whether a decision is solely automated and therefore whether the regime engages at all — a boundary at the entrance rather than a safeguard inside. Three patterns defeat it: batch approval, where a reviewer confirms two hundred outcomes in a sitting; insufficient information, where the reviewer sees a score and a recommendation but not the factors behind them; and genuine review that nothing recorded. The third is a records problem rather than a legal one, and it is the one that converts a defensible position into an indefensible one eighteen months later.
In depth: Human-in-the-loop vs autonomous AI agents: when involvement is meaningful
Denmark — NIS 2-loven and the bookkeeping act
Denmark has no B2B e-invoicing mandate. It does have three distinct requirements that English-language material all calls an audit trail.
NIS 2-loven
Lov om foranstaltninger til sikring af et højt cybersikkerhedsniveau, LOV nr 434 af 06/05/2025, in force 1 July 2025. Section 7 places approval of the security measures on the ledelsesorgan itself, together with supervision of implementation and mandatory training, and it cannot be delegated away. This is where Denmark and Germany diverge on one directive: the Danish body godkender, while the German Geschäftsleitung setzt um und überwacht — so a group operating in both countries cannot mirror its evidence, and a Danish board resolution does not satisfy § 38 BSIG.
In depth: NIS 2-loven: ledelsens ansvar for automatiserede og AI-drevne processer
bogføringsloven
The Danish Bookkeeping Act, LOV nr 700 af 24/05/2022. Booked transactions must not be capable of being changed, backdated or deleted; every entry carries a sequential transaction number, a registration date and initials for the user or program, and corrections are made by new entries rather than by amending old ones. The requirement that a bookkeeping system be able to send and receive e-invoices via Nemhandel and Peppol BIS is a system-capability requirement, not a duty to exchange them — Denmark has no B2B e-invoicing mandate, only mandatory B2G.
In depth: Krav til digitale bogføringssystemer: hvad reglerne faktisk siger
transaktionsspor
Under the bogføringslov, the connection between the individual booked entries and the company's annual accounts — it answers 'where in the annual accounts did this entry end up'. Retention is five years from the end of the financial year the material concerns. English-language material calls this an 'audit trail', which is how vendor documentation can promise one and deliver only this half of what Danish law requires.
In depth: Krav til digitale bogføringssystemer: hvad reglerne faktisk siger
kontrolspor
The other Danish requirement: the information documenting that the entries are correct — it answers 'why is this entry correct'. Same five-year retention, and the same English word covers it. A system can satisfy transaktionsspor completely and kontrolspor not at all, which is exactly what happens when an integration writes an entry with a tidy reference to a source system but records nothing about what triggered it.
In depth: Sådan skaber du et revisionsspor for AI-agenter
Nemhandel
The Danish e-invoicing infrastructure, with OIOUBL as its format, named alongside Peppol BIS in the digital bookkeeping system requirements. Only invoicing to the public sector is mandatory in Denmark; the rule addresses the system's capability rather than the company's behaviour, which distinguishes Denmark from Poland, Slovakia, Belgium and Norway. Also worth knowing: OIOUBL 3 was abandoned and Denmark is going straight to Peppol BIS 4, so material describing an imminent OIOUBL 3 migration is out of date.
In depth: Krav til digitale bogføringssystemer: hvad reglerne faktisk siger
Norway — digitalsikkerhetsloven and e-fakturering
NIS2 does not apply in Norway. The B2B e-invoicing obligation was adopted in June 2026 and is newer than most country guides.
digitalsikkerhetsloven
Norway's cyber security act, in force 1 October 2025, implementing NIS1 — not NIS2. NIS2 is marked EEA-relevant but has not been incorporated into the EEA Agreement: there is no EEA Joint Committee decision, and Norway therefore has no obligation to implement it. 'NIS2 applies in Norway via the EEA' is the commonest error in Norwegian content and is wrong in both halves. The act covers seven sectors, with registration at NSM and the sector authority and 24-hour reporting of significant incidents; NIS2 requirements nonetheless reach Norwegian suppliers contractually, through their EU customers' supply-chain duties.
In depth: Digitalsikkerhetsloven: hvorfor NIS2 ikke gjelder i Norge — og hva som gjør det
bokføringspliktig
A party subject to the Norwegian bookkeeping obligation — the class against which the e-invoicing duty is defined, including foreign companies with a Norwegian bookkeeping obligation, and excluding sales to consumers. The Storting adopted the change on 8 June 2026 and it was sanctioned on 19 June: sending is mandatory from 1 January 2027, while receiving and mandatory digital bookkeeping arrive only on 1 January 2030. That three-year asymmetry is unusual and has to be designed for, because from 2027 you must send to recipients who have no duty to be able to receive.
In depth: Obligatorisk e-fakturering fra 1. januar 2027: hva loven faktisk sier
EHF og ELMA
EHF (Elektronisk handelsformat) is the UBL-based domestic Norwegian format, with Peppol BIS Billing 3.0 used across borders; ELMA is Norway's Peppol SMP and address register, holding roughly 360,000 registered recipients. EHF 3.0 over Peppol is the expected outcome for the 2027 mandate but is not yet in regulation: the Directorate of Taxes was tasked with delivering format and exemption proposals by 15 December 2026, about two weeks before the duty takes effect. Build towards Peppol and EHF, but keep the format layer separable until the regulations land.
In depth: Obligatorisk e-fakturering fra 1. januar 2027: hva loven faktisk sier
Estonia — e-arve and küberturvalisus
Estonia has no general B2B e-invoicing mandate, and its NIS2 transposition landed roughly fourteen months late.
e-arve
An Estonian e-invoice: a machine-processable structured invoice. A PDF is not an e-arve even when emailed, because the criterion is machine-readability rather than electronic delivery, and the same applies to a scanned paper invoice or an image file. Where a buyer demands one the default format is EN 16931, usually Peppol BIS Billing 3.0 (UBL); EVS 923:2014 and UN/CEFACT CII remain possible by agreement. Estonia applies no national CIUS or extension on top of EN 16931, which makes cross-border integration simpler than in countries with a mandatory national profile.
In depth: E-arve Eestis: mida seadus tegelikult nõuab (ja mida mitte)
ostja õigus e-arvet nõuda
The buyer's right to demand an e-invoice — the actual Estonian rule, in force since 1 July 2025, and not a general mandate. Where the buyer is registered as an e-invoice recipient in the commercial register, the seller must issue an e-invoice unless the parties have agreed otherwise; the obligation arises from the buyer's choice rather than from the law at large. Roughly 15,000 entities are registered, so most Estonian companies cannot demand one. The 2027 general obligation is a December 2024 ministry white paper, not enacted law, and material presenting it as current law is wrong.
In depth: E-arve Eestis: mida seadus tegelikult nõuab (ja mida mitte)
küberturvalisuse seadus (KüTS)
Estonia's cyber security act. The amending act transposing NIS2 entered into force on 1 January 2026, roughly fourteen months after the EU deadline of 17 October 2024, and expanded the covered population from about 3,500 to about 6,500 entities under the supervision of the Riigi Infosüsteemi Amet (RIA). The management board must approve the risk-management measures, monitor their implementation and complete training. Estonia did not adopt the directive's optional temporary management ban — unlike Denmark and Belgium — so liability runs through company law, via the personal recourse claim under Commercial Code § 315(2).
In depth: Küberturvalisuse seadus ja NIS2: mis Eestis 1. jaanuaril 2026 muutus
Slovakia — Peppol 5-corner
Mandatory from 1 January 2027. It is not central clearing, and that decides where the risk sits in your integration.
Peppol 5-corner
The Slovak e-invoicing architecture: the four standard Peppol corners plus a fifth, Finančná správa, which receives the SK TDD. There is no state platform that approves and delivers the invoice. The consequence teams overlook most often is that delivery to the buyer and delivery of the SK TDD to the tax administration are two distinct events in two distinct flows — an invoice can be with the customer and in the accounts while the tax obligation remains unmet, and no platform will tell you.
In depth: Peppol 5-corner a digitálni poštári: ako v skutočnosti funguje slovenská e-fakturácia
digitálni poštári
Literally 'digital postmen' — certified Peppol access points additionally accredited by Finančné riaditeľstvo SR, which is itself the Slovak Peppol Authority and publishes the PASR requirements and the list of approved providers. Authenticity of origin and integrity of content rest on the secure AS4 protocol between two mutually authenticated access points, not on a document-level signature. An archive of signed PDFs therefore no longer proves what it proved before; the transmission record becomes the evidence, and it exists only if someone deliberately retains it.
In depth: Peppol 5-corner a digitálni poštári: ako v skutočnosti funguje slovenská e-fakturácia
SK TDD (SK Tax Data Document)
The tax data document derived from the invoice and sent to Finančná správa as the fifth corner. Because no central authority reconciles the two flows, the period-close control has to compare three sets against each other: invoices issued, deliveries confirmed, and SK TDDs confirmed. If those three sets are not equal you have a problem that nobody will report to you — in a centralised model the platform would have.
In depth: Peppol 5-corner a digitálni poštári: ako v skutočnosti funguje slovenská e-fakturácia
SMP (Service Metadata Publisher)
The registry that tells senders where to deliver documents addressed to you. Registration is unique, so an entity can have exactly one provider for receiving and several for sending — an asymmetry that makes the receiving provider a single point of failure with no alternative route. Changing provider is not an instant operation: the SMP record has to be rewritten and propagated across the network, which puts provider availability and handover time in the business continuity plan rather than the contract's small print.
In depth: Peppol 5-corner a digitálni poštári: ako v skutočnosti funguje slovenská e-fakturácia
Belgium — structured e-invoicing
Live since 1 January 2026 with no phasing. The tolerance ended on 31 March 2026 and was not extended.
gestructureerde elektronische factuur / facture électronique structurée
Structured e-invoicing has been mandatory in Belgium since 1 January 2026 for taxable persons established in Belgium on their Belgian B2B operations, with no phasing by company size and no turnover threshold. The three-month administrative tolerance ended on 31 March 2026 and was not extended; a separate, narrower tolerance for self-billing ran to 30 June 2026. Belgium uses a four-corner Peppol model with Peppol BIS Billing 3.0 (UBL) as the default, and a recipient may not refuse a structured invoice on format grounds. The commonest misreading is the article 44 exemption: it covers only taxable persons carrying out exclusively exempt operations, so a mixed taxable person is not exempt.
In depth: Facturation électronique B2B en Belgique : l'obligation depuis 2026 et le e-reporting 2028
United States — automated decision-making
No federal AI statute binds private companies. What binds you is a short list of state instruments — one of which never took effect at all.
ADMT (automated decision-making technology)
The California Privacy Protection Agency's term, and the closest thing the United States has to a general automated-decision regime. The definition is narrower than most assume: technology that processes personal information and replaces or substantially replaces human decision-making, biting on significant decisions in financial or lending services, housing, education, employment or independent contracting, and healthcare. Behavioural advertising was dropped from the final rules. The framework took effect on 1 January 2026, ADMT duties apply from 1 January 2027, the first risk-assessment summary filing is due 1 April 2028, and risk assessments carry five-year retention.
In depth: Automated decision-making compliance in the US: what actually applies in 2026
TRAIGA (Texas Responsible Artificial Intelligence Governance Act)
Texas HB 149, in force 1 January 2026. Its prohibitions are intent-based, and disparate impact alone is not sufficient to prove intent. Enforcement is Attorney-General only, with a 60-day cure period. It reaches a different thing from Illinois HB 3773, which is why a control set optimised to one of them under-serves the other.
In depth: Automated decision-making compliance in the US: what actually applies in 2026
Illinois HB 3773
In force 1 January 2026, amending the Illinois Human Rights Act. It bars AI with a discriminatory effect in employment decisions, bars the use of zip code as a proxy, and requires notice. Note the contrast with Texas: Illinois reaches effect, TRAIGA reaches intent, and the two tests are not satisfied by the same evidence.
In depth: Automated decision-making compliance in the US: what actually applies in 2026
Colorado AI Act (SB 24-205)
It never took effect. Signed in May 2024 with a February 2026 operative date, it was delayed twice, its enforcement was suspended under a stipulation in litigation against the state, and it was repealed and reenacted by SB 26-189, signed 14 May 2026 and effective 1 January 2027. Nobody ever complied with SB 24-205, because it never applied. Content describing its duty of care, algorithmic impact assessments or risk-management-programme requirement is describing a law that was repealed before it operated; the replacement is materially lighter and disclosure-based, with meaningful human review, pre-use notice, adverse-outcome disclosure within 30 days and data correction.
In depth: Automated decision-making compliance in the US: what actually applies in 2026
Kenya — eTIMS and data protection
eTIMS return validation runs from the 2026 tax year. Kenya has no AI law; section 35 of the Data Protection Act is closer to the European model than the American one.
eTIMS
Kenya's electronic Tax Invoice Management System. From the 2026 tax year, all income and expenses declared in income tax returns must be supported by valid electronic tax invoices generated and transmitted through eTIMS or TIMS; the one-year transitional relief applied only to 2025 returns and ended with the 30 June 2026 filing deadline. It binds all persons carrying on business, not only VAT-registered taxpayers — the point most often misunderstood — including non-VAT entities supplying exempt goods and services such as hospitals, schools and NGOs.
In depth: eTIMS validation: why every expense now needs an electronic tax invoice
TIMS
The Tax Invoice Management System that preceded eTIMS, and against which KRA also validates. Return validation matches declared income and expenses against TIMS and eTIMS invoices, withholding tax data and customs import records — which shifts where the consequence lands: your supplier's failure to transmit becomes your disallowed deduction. The buyer PIN is the field that decides whether your customer can deduct at all, and its absence is discovered at filing rather than at purchase.
In depth: eTIMS validation: why every expense now needs an electronic tax invoice
OSCU (Online Sales Control Unit)
The eTIMS control-unit model for systems that are continuously online. Its constant-connectivity requirement is a real constraint in Kenyan operating conditions: a system on OSCU that loses connectivity must either stop invoicing or queue, and a queue without an idempotency key attached before the first transmission attempt will duplicate invoices on reconnection.
In depth: eTIMS validation: why every expense now needs an electronic tax invoice
VSCU (Virtual Sales Control Unit)
The eTIMS control-unit model for high-volume invoicing and environments without continuous connectivity, supporting batched and offline operation. It exists partly to avoid the OSCU reconnection problem, and for any high-volume or distributed operation it is usually the safer architecture. Choose between the two on connectivity, not convenience.
In depth: eTIMS validation: why every expense now needs an electronic tax invoice
Data Protection Act 2019, section 35
Kenya's automated-decision rule, and stricter than many organisations running scoring, screening or eligibility models there assume. The operative words are 'not to be subject to' a decision based solely on automated processing, including profiling, which produces legal effects or significantly affects the data subject — a right against the decision itself, not merely a duty to disclose that a machine was involved. Three exceptions exist (contract necessity, legal authorisation with suitable safeguards, express consent), and even inside them the data subject may request reconsideration or a new decision not based solely on automated processing. Kenya retains the shape the UK left behind in February 2026, so a group that rolled its post-DUAA policy out to a Nairobi entity has under-protected there.
In depth: Automated decisions under Kenya's Data Protection Act: what section 35 actually requires
Cross-market standards
Three instruments recur beneath the national mandates and are worth separating from them.
EN 16931
The European standard for electronic invoicing, and the common floor beneath almost every mandate in this library: German E-Rechnung conformity, the three French formats socles, the Slovak and Belgian Peppol BIS profiles and the Estonian default format. Conformity is a property of the profile rather than of the format family — ZUGFeRD in MINIMUM or BASIC-WL is not EN 16931 conformant even though the file validates as ZUGFeRD, which is why an inbound check needs a profile test and not only a format test.
In depth: Factur-X, UBL et CII : comprendre les formats de la facturation électronique
Peppol
The interoperability network behind most decentralised European mandates: four corners in Belgium and Norway, five in Slovakia, and confirmed in June 2026 as the core interoperability network for the UK mandate from 2029. What it does not give you is duplicate detection. In a decentralised model no central authority flags a second document, so a retry after a timeout puts two invoices into circulation and the counterparty is the one who finds out.
In depth: Peppol 5-corner a digitálni poštári: ako v skutočnosti funguje slovenská e-fakturácia
ViDA (VAT in the Digital Age)
Council Directive (EU) 2025/516, in force since 14 April 2025. It sets the two dates that survive national uncertainty: digital reporting obligations for intra-Community B2B supplies from 1 July 2030, and convergence of existing national reporting systems to the EU model by 1 January 2035. Where a national system is announced but undated — Germany's Meldesystem has no date and no Referentenentwurf — these are the only defensible anchors for a roadmap.
In depth: E-Rechnung, Automatisierung und KI — der vollständige Leitfaden
Cross-market technical vocabulary
The engineering terms that decide whether a compliance obligation is met in practice. No regulation names AI agents; these are the concepts the regulations reach through.
Model Context Protocol (MCP)
The protocol through which agents reach tools and data. The 2026-07-28 release added human-approval and enterprise authorization primitives to the protocol — and in the same move shifted the security boundary out of the protocol and into whatever each vendor implements. The specification is marked Current, not Final, so it may still take backwards-compatible changes; a deprecated feature must remain at least twelve months before removal, floored at ninety days on the expedited path, which makes ninety days your worst-case upgrade window.
In depth: MCP security after the 2026-07-28 specification
tool call
The unit at which an agent actually does something, and the correct unit of permission review. Access is normally granted at the server, but a single MCP server typically exposes read, list and create operations and very often delete or configuration operations — so an agent that needs one read tool is handed the destructive ones permanently, because they arrived in the same package. An inventory must enumerate tools by name; a count is not a register.
In depth: MCP governance: managing Model Context Protocol servers in an organisation
pre-execution authorization
A control that runs before the action, and the only kind that changes the outcome of an irreversible one. Detective controls report that something happened; corrective controls reverse it where reversal exists. An invoice accepted into a national e-invoicing system, a cleared payment and a credential sent to an attacker-controlled endpoint admit neither. The threshold has to be enforced in a layer the agent passes through and cannot reconfigure — if the model decides whether it needs supervision, there is no control.
In depth: Approving AI agent actions before execution
human-in-the-loop
A design label, not a legal status. Four jurisdictions ask a version of the same question in four vocabularies — the UK's meaningful human involvement, Colorado's meaningful human review, California's 'replaces or substantially replaces human decision-making', and Switzerland's review by a natural person — and none is satisfied by an architecture diagram with a person in it. A functioning loop needs authority to reach a different outcome, the information required to reach it, and a record of what the reviewer was shown. A zero override rate across ten thousand cases is evidence against the loop, not for it.
In depth: Human-in-the-loop vs autonomous AI agents: when involvement is meaningful
idempotency key
A stable, deterministic identifier assigned to an operation before its first attempt, so that a retry after a timeout presents the same value and produces no second document. The near-universal implementation error is generating the key inside the dispatch function, so every attempt mints a fresh one: the mechanism is present, configured, and doing precisely nothing. The key belongs to the workflow's durable state, not to the retry path — and the receiving system's deduplication window is a second clock you do not own, which Stripe for instance documents as 24 hours.
In depth: Approval checkpoints: what happens to the workflow while it waits
durable state
Execution state serialised to storage that outlives every process — a row rather than a running thread. It is what separates a wait that survives a deploy, an autoscaler scale-in or a worker eviction from one that does not, and the builder canvas looks identical either way. Durability guarantees that the run comes back; it guarantees nothing about how many times the thing at the end of it happens, because durable engines document activity execution as at-least-once.
In depth: Approval checkpoints: what happens to the workflow while it waits
checkpoint-and-resume
The pattern in which the engine deliberately ends the execution, serialises its position in the graph, its variable state and a correlation identifier to durable storage, releases the worker, and reconstitutes a materially identical run when the approval arrives carrying that identifier. Its opposite is pause-and-wait, which holds the run in process memory, so anything that ends the process ends the wait. The test takes ten minutes: pause a run, redeploy, approve — one correct completion and exactly one downstream artefact means the checkpoint is real.
In depth: Approval checkpoints: what happens to the workflow while it waits
audit trail (as distinct from an application log)
A record written before each action into storage the writing process cannot alter, holding the trigger, the input data the decision rested on, the model and configuration version in force, the approver and what they were shown, and the outcome — retained for the period the obligation requires. Application logs fail on all four counts: retention set by storage cost, a writer that can overwrite and delete, completeness that depends on a log level adjusted informally in production, and linkage to a request ID rather than to the document, decision, actor and policy version. Nobody asks what happened in request 7f2a91; they ask who cancelled this order and who allowed it.
In depth: How to build an audit trail for AI agents
evidence receipt
A signed record of what was authorised, issued at the moment of authorisation rather than assembled afterwards. The distinction it carries is between 'approved at 14:32' and 'approved at 14:32, having been shown these parameters' — the first is a log line, the second is evidence. Where an approval screen renders live data at click time, the record can say a payment was approved and imply a figure that was never the one approved; the fix is to snapshot the payload, hash it, render from the snapshot and re-verify the hash at dispatch.
In depth: Approval checkpoints: what happens to the workflow while it waits
tenant isolation
What actually separates one client's data, credentials and execution from another's — as opposed to folders, tags and prefixes, which separate human navigation only. A workflow definition is inert; a credential is capability, so scoping workflows without scoping the connections they can reach gives you a tidier interface and exactly the tenancy boundary you had before. The two things that fail across every tenant simultaneously are the credential encryption key and the version pins, and almost nobody reviews either.
In depth: Running client workflows: isolation, credentials and blast radius
blast radius
The governing constraint in multi-client automation: the guarantee that one client's misconfiguration, leaked credential or runaway loop cannot reach another client's data. It is a consequence question rather than an architecture-purity one — a marketing workflow and a payment-approval workflow do not need the same boundary. Offboarding is the only test that returns an unambiguous answer: hand over runnable workflows, delete the client's data including execution history, and revoke every credential in every connected system, each of them provably.
In depth: Running client workflows: isolation, credentials and blast radius
agentic scope creep
An agent exceeding the authority somebody assumed its instructions carried, while following those instructions correctly. FINRA's 2026 Annual Regulatory Oversight Report names scope creep beyond intended authority as a supervisory risk, alongside autonomy without human validation and auditability of multi-step reasoning — a regulator naming it in an official report is the strongest citation available for agentic governance in US financial services. Better prompting does not close it: a prompt is a request the model can reason its way around, and if changing the system prompt can change what the agent may do, the permission lives in the model's context and anything reaching that context can move it.
In depth: FINRA on AI agents: what the 2026 oversight report actually says
Why terminology precision matters for compliance search
Searching faktura ustrukturyzowana and searching e-faktura return different worlds. The first returns the Polish mandate, art. 106ni, the FA(3) structure and the offline modes. The second returns invoicing software marketing across a dozen countries, most of it about a legal object that does not exist in Polish law. The same fork appears everywhere in this library, and it is not a matter of style.
Search for PDP and you get French material written before 27 July 2026, which pre-dates the abandonment of the free public portal for issuing — a structural change, not a rename. Search for Verarbeitung and Datenschutz-Grundverordnung and you get the DSGVO, which prohibits automated decisions with exceptions; the Swiss DSG uses Bearbeitung and does not prohibit them at all, it grants a right to human review. Search for audit trail in Denmark and you collapse three separate requirements — Datatilsynet’s logging duty, transaktionsspor and kontrolspor — into one word that satisfies none of them individually. Search for NIS2 Norway and you find advice built on a directive that has never been incorporated into the EEA Agreement.
The pattern is consistent: the imprecise term is the one that returns the most results, and the precise term is the one that returns the applicable law. That holds for a person with a search box and for a generative system assembling an answer. It also has a defensive use — if a supplier’s documentation, a training deck or an internal procedure uses the loose term where the authority uses the strict one, that is a reliable signal that the document was written from secondary sources, and worth checking against the primary instrument before anyone relies on it.
Where the terminology leads
Across every market above, the vocabulary differs and the underlying question does not: what did the system do, on what basis, with whose authorisation, and can you show it long after the fact. BarzelVault enforces policy and approval thresholds in a layer the agent passes through and cannot bypass, and records each action with its inputs, policy version and approver before it executes. Barzel Central Gateway federates and routes the tool calls; Barzel FinOps Atlas attributes cost to outcomes; BarzelOps runs governed cross-system workflows on durable state.
Cross-market guides
- AI agent governance: control before execution, evidence after
- Governed workflow automation: the cost of a platform is the exit
- FinOps for AI agents: cost per workflow and per action
- MCP governance: managing MCP servers in an organisation
- How to build an audit trail for AI agents
- How to scope AI agent permissions
- Preventing unauthorised AI agent actions
- Workflow portability: what to ask before you commit
Markets in English
In local languages
- Polska
- Deutschland
- France
- Schweiz / Suisse
- United Kingdom
- United States
- Danmark
- Belgique / België
- Norge
- Slovensko
- Eesti
- Kenya