Credit notes, corrections and cancellations: the documents that break integrations

Every mandate demo shows a clean invoice going out and clearing. That is the easy 80%. The other 20% — the credit note, the corrective invoice, the cancellation — is where regimes diverge, where the EN 16931 references have to line up exactly, and where integrations that passed every happy-path test quietly start failing in week three. This is a field guide to the document types nobody scopes and everybody eventually has to fix.

1. Why corrections are the hard part

A first invoice is a standalone document — it references nothing and depends on nothing. A correction is a relationship: it only makes sense in terms of the document it amends, and both the tax authority and the buyer have to be able to follow the thread from the correction back to the original. That relationship is what integrations get wrong, because it is the part the happy path never exercises.

It is also where the money and the audit risk sit. A wrong correction understates or overstates VAT, breaks the buyer's input-tax deduction, and leaves an orphaned document the authority cannot reconcile. Under clearance, a botched correction can also mean you have a cleared invoice you can no longer lawfully undo.

2. The document types, and their codes

"Correction" is an umbrella over several distinct documents, and EN 16931 carries the distinction in the invoice type code (UNTDID 1001). Getting this code right is half the battle, because it tells the receiver and the authority how to treat the document.

The trap is assuming one mechanism is universal. Some regimes correct by credit note (reverse and re-issue); others define a dedicated corrective/rectifying invoice that replaces the original. A build that only emits 380 and 381 will meet a mandate that expects a 384 corrective and fail validation for a document it does not know how to produce.

3. You usually cannot just delete

The instinct from a pre-mandate world is to cancel a wrong invoice and re-issue. Under most e-invoicing mandates you cannot. Once a document has been cleared by the authority or exchanged over the network, it exists — there is no delete button on a tax administration's records. You correct it with another document: a credit note that reverses it, or a corrective invoice that supersedes it.

There are narrow exceptions — some regimes allow a true cancellation within a short window before the invoice is acted on — but the safe default is: corrections are additive. Design the system so "cancel" produces a compensating document with the right type code and a reference back, not a row deletion. Teams that model cancellation as a delete discover during the first real mistake that the authority still has the original and now sees an unexplained gap.

In a clearance world there is no undo — only a document that says "disregard the last one". Model cancellation as issuance, never as deletion.

4. Referencing the original: where it breaks

Every correction has to point at what it corrects, and this is the single most common cause of a rejected corrective document. In EN 16931 the link is carried by the preceding invoice reference (BT-25) and its issue date (BT-26), on the document header. Get these wrong and the correction is either rejected outright or accepted as an orphan the authority cannot match.

The places it goes wrong are predictable:

• The reference is your internal number, not the legal one. In a clearance regime the original's identity is often the authority-issued identifier (the cleared ID), not your ERP document number. Reference the wrong one and the match fails.
• The date is missing or in the wrong format. Where a national specification makes the preceding-invoice reference mandatory on corrections — base EN 16931 leaves the whole group (BG-3) optional — its issue date (BT-26) generally has to travel with it, and an omitted or mis-formatted date fails the rule just as a missing reference does.
• A credit note references nothing at all. Base EN 16931 does not force a preceding reference, so a document can be locally valid and still rejected by a national rule that requires it — a classic "passes Schematron, still rejected" case.
• One-to-many corrections. A single credit note covering several invoices, or one invoice corrected twice, needs a referencing model that copes with more than a tidy one-to-one link.

5. Where regimes diverge

The corrective layer is exactly where national specifications stop agreeing with each other. A few of the axes to check for every country in scope:

• Mechanism: credit note vs dedicated corrective invoice. Italy expresses a credit note as a FatturaPA document type (TD04); Poland has a defined corrective invoice (faktura korygująca) with its own handling in KSeF; Romania corrects within the RO e-Factura flow.
• Buyer acceptance: some regimes let the buyer formally accept or reject a correction, which becomes a document in its own right you must capture.
• Negative amounts: whether a reduction is expressed as a credit note (positive amounts, credit semantics) or as negative lines — and some validators reject negatives outright.
• Time limits: how long after the original you may issue a correction, and whether it must fall in the same tax period.
• Reason codes: whether a structured reason for the correction is mandatory.

None of these is exotic; all of them are routinely missed because the happy-path invoice sailed through and the corrective cases were never built. Our note on why a valid file still gets refused — your Schematron passes and the invoice is still rejected — is, in practice, most often a story about a correction.

6. Building for the lifecycle

The fix is to treat the invoice as a lifecycle, not a document, from day one:

1. Model the relationships. An invoice can be superseded, credited (wholly or partly, once or many times) and referenced. Build that graph, not a flat table of documents.
2. Persist legal identifiers. Keep the authority-issued ID next to every cleared document so corrections can reference it correctly.
3. Emit every type code you might need — 381, 383, 384 and any national corrective — not just the original 380.
4. Make BT-25 / BT-26 first-class and validate them against the national rule, not just base EN 16931.
5. Test the unhappy paths end to end: full credit, partial credit, correction-of-a-correction, cancellation, one credit note across many invoices. Each against the authority, not just your local validator.

Do this at the start and corrections are a well-understood branch of the same flow. Bolt it on after go-live — which is the norm — and you are debugging tax-relevant documents in production, under a clock, with the buyer's input-tax deduction on the line. The 20% is where the real engineering is; scope it like it matters.