Credit Notes & Corrections as E-Invoices: Type Codes Done Right

Issuing an invoice as an e-invoice is well understood. Issuing a credit note or a correction as an e-invoice is where a lot of otherwise-valid files get rejected — not because the amounts are wrong, but because the document type and the reference to the original were not set correctly. This article walks through exactly which codes to use and which fields must be present.

> Short answer: Set the document type in BT-3 (UNTDID 1001) using the German subset from BR-DE-17: 380 invoice, 381 credit note, 384 corrected invoice, 389 self-billed, 326 partial. A correction or credit note must reference the original invoice via BG-3 — number in BT-25 and date in BT-26 — or BR-DE-26 will reject it.

The type code lives in BT-3

Every EN 16931 invoice carries a document type code in the business term BT-3, drawn from the UNTDID 1001 code list. This single field tells the recipient's system whether the document is an invoice, a credit note, or a correction — and it drives how the amounts are posted.

Germany does not allow the full UNTDID list. The rule BR-DE-17 restricts BT-3 to a subset:

Any other code fails BR-DE-17. So the first rule is simple: pick the right value from this list.

381 vs. 384: credit note or correction?

The most consequential distinction is between 381 and 384:

• 381 — credit note. A full credit: you are reversing a charge, whether because goods were returned, a discount was granted after the fact, or the original invoice is being cancelled outright.
• 384 — corrected invoice. A correction of individual values in a prior invoice — a wrong quantity, a wrong price, a wrong tax rate. The document supersedes specific figures rather than reversing the whole charge.

Choosing 381 when you mean 384 (or vice versa) produces a technically valid file that still books incorrectly at the recipient. Get the intent right, then get the code right.

Always reference the original: BG-3, BT-25, BT-26

A credit note or correction that does not say what it corrects is meaningless — and German rules enforce that. You must populate the group BG-3 ("preceding invoice reference"):

• BT-25 — the number of the original invoice
• BT-26 — the date of the original invoice

If this reference is missing on a document that requires it, BR-DE-26 rejects the file. This is one of the most common reasons corrections bounce: the amounts and type code are fine, but the link back to the original was never set. (See other frequent XRechnung rejection reasons.)

Credit note (381) vs. self-billed invoice (389)

These two are routinely confused because both can *look* like "the other party got billed":

• A commercial credit note (381) is issued by the seller to reduce or reverse an amount they previously charged.
• A self-billed invoice (389) is issued by the buyer on the supplier's behalf, under a self-billing agreement — the buyer creates the invoice the supplier would normally have sent.

They are different documents with different legal meaning. Using 389 for what is actually a commercial credit note misrepresents who issued the document. Only use 389 where a genuine self-billing arrangement exists.

A worked example

Suppose invoice 2026-0421 dated 3 June 2026 charged for 12 units, but only 10 were delivered. You have two clean options:

1. Full credit + reissue. Issue a 381 credit note referencing 2026-0421 (BT-25 = 2026-0421, BT-26 = 2026-06-03), then a fresh 380 for the correct 10 units.
2. Corrected invoice. Issue a 384 referencing 2026-0421 that restates the line at the correct quantity.

Either is valid; both must carry the BG-3 reference. What is *not* valid is a bare 381 with no reference to 2026-0421 — that fails BR-DE-26.

Everything else still applies

A credit note or correction is still a full EN 16931 document. All the usual mandatory fields apply, the KoSIT rules still run, and you should still validate before sending. The type code and reference are additions, not replacements.

Set the type code correctly from a PDF

If your credit note or correction already exists as a PDF, you do not have to hand-build the XML to get BT-3 and the reference fields right.

TaxLayer lets you select the document type on conversion, so the correct BT-3 code and the BG-3 / BT-25 / BT-26 reference are set on the generated e-invoice. The first two conversions each month are free — no credit card required.