Since 1 January 2025 German B2B businesses are subject to an unrestricted obligation to receive e-invoices based on EN 16931 (BMF 2024-10-15). Any business that issues invoices via its online shop must apply the same diligence to cancellation invoices, credit notes and corrections — these documents are explicitly covered by the new obligation (§ 14 (2) sent. 5 UStG). According to Bitkom, the German ICT market will grow to 245.1 billion EUR in 2026 (+4.4 per cent), and ZUGFeRD 2.3 was released on 2024-09-18 in line with EN 16931 (FeRD/AWV). This article shows how to separate the three BT-3 invoice type codes 380, 381 and 384 in a Shopware workflow and how to implement them in a GoBD-compliant manner.
German e-invoicing deadlines at a glance
With the German Growth Opportunities Act (Wachstumschancengesetz), § 14 UStG has been in force since 2024-12-31 (BMF). Since then the receive obligation applies without restrictions: every German B2B business must be able to process structured e-invoices. The BMF circular explicitly names XRechnung and ZUGFeRD from version 2.0.1 as valid formats (BMF/KoSIT). For the sending side, legislators defined staggered transitions — the following table summarises who is affected by which cut-off date.
For shop operators the calendar is clear: anyone already selling B2B today must be able to electronically process incoming ZUGFeRD or XRechnung documents — which typically includes credit notes and cancellation documents from suppliers. The send obligation follows in stages but is not optional: from 2028 onwards it applies without exception to all B2B revenue (BMF). In practice this means every Shopware shop should have a fully functional ZUGFeRD send pipeline in place by 2027 — including clean handling of all cancellation and correction scenarios, because these often represent the critical case in invoice transmission.
| Cut-off date | Obligation | Affected parties | Source |
|---|---|---|---|
| 2025-01-01 | Receive obligation (unrestricted) | All German B2B businesses | BMF 2024-10-15 |
| 2027-01-01 | Send obligation | Businesses with previous-year revenue above 800,000 EUR | BMF |
| 2028-01-01 | Send obligation (without exception) | All B2B businesses | BMF |
Relevant for e-commerce: according to § 14 (2) sent. 5 UStG, the receive and send obligations also extend to credit notes — meaning all invoice corrections that reverse or adjust an original service invoice (BMF). Anyone still sending these documents as PDF or paper violates the new format requirement. We covered the basics in our previous article on the e-invoicing obligation 2026 for online shops.
Cancel, credit, correct: three documents, three codes
EN 16931 encodes the invoice type in field BT-3 (Invoice Type Code). Three codes are relevant for day-to-day shop operations: 380 for the regular invoice, 381 for credit note or cancellation and 384 for the corrected invoice (EN 16931/KoSIT). The distinction is more than formal — it determines how the document is processed in accounting software and in the DATEV integration. Getting it wrong leads to booking issues at the recipient and to queries from the tax authorities.
| BT-3 code | Document | Typical situation | Special aspect |
|---|---|---|---|
| 380 | Invoice | Regular shop sale | Default case |
| 381 | Credit note / cancellation | Full reversal of an invoice | Amounts positive, no minus sign |
| 384 | Corrected invoice | Partial correction (price, quantity, tax) | BG-3 Preceding Invoice Reference required |
BT-3 invoice type code: when to use what?
Code 381 is the classic choice for cancellations and commercial credit notes: an issued invoice is fully reversed, for example after a return or a withdrawal. According to the E-Rechnung-Bund FAQ there is a rule that surprises many shop operators: amounts must be stated as positive values — the minus sign is not written into the numbers but implied by code 381 (E-Rechnung-Bund FAQ). Here is a minimal example in the ZUGFeRD BASIC profile.
In many Shopware installations this point is the most common source of validation errors: teams coming from classical invoice correction reflexively write negative values into the XML and then wonder why recipient systems reject the file as invalid. The clean approach is a template logic that centrally sets the document type, takes amounts without sign and keeps all header and line totals consistent. An inconsistent summary field (for example when LineTotalAmount and GrandTotalAmount do not match) fails Schematron validation just as reliably as a missing tax breakdown (KoSIT).
<rsm:CrossIndustryInvoice xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100">
<rsm:ExchangedDocument>
<ram:ID>INV-2026-001-C</ram:ID>
<ram:TypeCode>381</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20260422</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
<rsm:SupplyChainTradeTransaction>
<ram:ApplicableHeaderTradeSettlement>
<ram:SpecifiedTradeSettlementHeaderMonetarySummation>
<ram:LineTotalAmount>1000.00</ram:LineTotalAmount>
<ram:TaxBasisTotalAmount>1000.00</ram:TaxBasisTotalAmount>
<ram:GrandTotalAmount>1190.00</ram:GrandTotalAmount>
</ram:SpecifiedTradeSettlementHeaderMonetarySummation>
</ram:ApplicableHeaderTradeSettlement>
</rsm:SupplyChainTradeTransaction>
</rsm:CrossIndustryInvoice>Code 384 (Corrected Invoice) is used whenever the invoice is not fully cancelled but individual line items or values are adjusted — for example a wrong tax rate or an accidentally wrong quantity. Unlike code 381, code 384 requires a mandatory reference to the preceding invoice (KoSIT). More on that in the next section.
The clean separation between 381 and 384 pays off at the latest in accounting: a cancellation with code 381 is recorded in many ERP systems as a separate booking entry that resolves the original receivable. A correction with code 384, by contrast, is treated as an adjustment entry that modifies the existing receivable — including the VAT delta. For partial returns or quantity adjustments in a B2B context, do not reflexively reach for 381: code 384 is typically the commercially and fiscally cleaner choice because it transparently continues the history of the original document.
BG-3 Preceding Invoice Reference: required fields
Corrected invoices with code 384 must uniquely reference the original invoice. EN 16931 uses the business group BG-3 (Preceding Invoice Reference) with the required field BT-25 (Preceding Invoice Reference) for the number and the optional BT-26 (Preceding Invoice Issue Date) for the date (KoSIT). If the predecessor invoice number is not unique, BT-26 becomes de facto required through KoSIT validation.
<rsm:ExchangedDocument>
<ram:ID>INV-2026-001-C</ram:ID>
<ram:TypeCode>384</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20260423</udt:DateTimeString>
</ram:IssueDateTime>
</rsm:ExchangedDocument>
<!-- BG-3: Preceding Invoice Reference -->
<ram:ApplicableHeaderTradeSettlement>
<ram:InvoiceReferencedDocument>
<ram:IssuerAssignedID>INV-2026-001</ram:IssuerAssignedID>
<ram:FormattedIssueDateTime>
<qdt:DateTimeString format="102">20260315</qdt:DateTimeString>
</ram:FormattedIssueDateTime>
</ram:InvoiceReferencedDocument>
</ram:ApplicableHeaderTradeSettlement>- BT-25 (Invoice Reference) — number of the preceding invoice, required field for code 384 (KoSIT)
- BT-26 (Preceding Invoice Issue Date) — date of the preceding invoice, de facto required when number ranges are not unique (KoSIT)
- BG-3 as a business group wraps both fields and unambiguously references the preceding document
- ZUGFeRD 2.3 in the EXTENDED profile also allows a defined rounding tolerance for correction amounts (FeRD)
- ZUGFeRD 2.3 is technically based on UN/CEFACT CII SCRDM D22B and backwards-compatible with D16B (FeRD)
GoBD-compliant cancellation workflows
Germany's principles for the proper management and retention of books (GoBD) contain a clear rule: once an invoice has been sent to the recipient, it must not be edited any more. Corrections must only happen through a cancellation invoice plus re-issue (GoBD). This applies regardless of format — even a locally created PDF from a Shopware shop that has already been emailed to the customer is considered fixed under GoBD. In combination with ZUGFeRD this means: cancellation and correction are standalone documents with their own number and BT-3 code.
A well-documented cancellation workflow translates this requirement into code by marking the original invoice as immutable in the database after dispatch. Any access that would modify the document instead creates a new record — either a cancellation (381) or a correction (384). Shopware 6 supports this pattern via the document service; for audit-proof archiving we additionally recommend a signature or hash value per document, written into the audit log. This ensures traceability at any time of who created which document when — a requirement that is regularly queried explicitly in GoBD audits (GoBD).
Especially in e-commerce environments with high return volumes, a clear event architecture pays off: a return event in the shop deterministically triggers a cancellation or corrected invoice, the CRM record is updated synchronously, and the accounting system receives the ZUGFeRD document without manual intermediate steps. This not only reduces errors but also closes a typical GoBD gap — the manual reworking of documents via spreadsheets or notes, which regularly causes discussion during audits.
Editing a sent invoice in the backend later on violates GoBD immutability (GoBD). The correct approach is always cancellation (381) + corrected invoice (384) or cancellation (381) + new invoice (380) — even when only the VAT rate was calculated incorrectly.
Shopware 6: creating cancellation documents
Shopware 6 in its Community Edition supports the document types invoice, cancellation, credit note and delivery note and can export them with BT-3 codes 380, 381 and 384 (Shopware). Cancellation documents can be created directly from the order view in the administration or re-generated via CLI or API without overwriting the original document. An older Shopware community forum thread discusses a greyed-out cancel button in specific order states as a known limitation (Shopware Community Forum) — a point we typically address in customer projects by designing a clean order state choreography.
In production setups we connect document creation to workflow events: as soon as a return is approved in the shop (see our article on returns management in e-commerce and the withdrawal button article), the system automatically triggers cancellation and, where needed, a corrected invoice — including ZUGFeRD export into the accounting system.
Another practical tip concerns number range design: cancellations (381) and corrections (384) should receive their own suffixes or their own number ranges — for example INV-2026-001 for the invoice, INV-2026-001-C for the cancellation and INV-2026-001-K for the correction. That way all three documents are visibly related at a glance but still referenceable via unambiguous IDs. In the Shopware administration this scheme can be configured cleanly via document number ranges. What matters is that the invoice number of the original document is not reused — typically this is not only GoBD-critical but also breaks the link between original and correction document at file level in many accounting systems.
Colloquial credit note vs. § 14 UStG credit note
In everyday shop language, credit note often refers to a reduction of the original invoice — e.g. after a return or a discount. German tax law additionally knows the credit note in the sense of § 14 (2) UStG: a billing document issued by the recipient of the service. Only the latter can trigger an unjustified tax statement under § 14c UStG. The commercial cancellation credit note is not affected by this (BMF).
For ZUGFeRD practice this means: a colloquial credit note (e.g. refund after a return) is technically mapped as a cancellation with BT-3 = 381 or a correction with BT-3 = 384 — not as a separate document under § 14 (2) UStG. If you want the word credit note to appear in the PDF layer, the distinction should be clearly communicated in the template to avoid confusion with the tax-law credit note.
In our Shopware projects we recommend a template variable that outputs a different heading depending on the BT-3 code — for example Cancellation invoice for 381 with a reference to the original invoice and Corrected invoice for 384 with explicit naming of the changed line items. The word credit note is then reserved for real § 14 UStG scenarios. For the recipient this is not only more readable but also prevents the invoice from being accidentally interpreted as a separate billing document under § 14c UStG — a risk the tax authorities can examine when document labels are unclear (BMF).
Typical mistakes in corrected invoices
- Minus sign in code 381 — amounts must be positive; the minus is implied by the code (E-Rechnung-Bund FAQ)
- Missing BG-3 reference in code 384 — without BT-25 the KoSIT validation fails (KoSIT)
- Same invoice number as the original — a cancellation needs its own number, otherwise accounting systems break the link
- Editing the original invoice in the backend — violates GoBD immutability (GoBD)
- ZUGFeRD 1.0 instead of 2.0.1+ — from 2025 only versions from 2.0.1 are recognised as valid e-invoices (BMF)
- Wrong BT-3 code for discount add-ons — partial discounts are typically 384 (correction), not 381 (cancellation)
- Using the word credit note in the document without delimiting § 14 (2) UStG — risk of § 14c discussion (BMF)
- Rounding differences in partial corrections — explicitly addressed in the ZUGFeRD 2.3 EXTENDED profile (FeRD)
Accounting integration: DATEV and beyond
A cleanly coded cancellation invoice or correction is only operationally useful if it is automatically booked in accounting as a reduction of the original document. Our DATEV integration processes the BT-3 codes and the BG-3 reference directly; we describe more in our article on the DATEV integration for e-commerce accounting. For larger ERP environments — for example in combination with Dynamics 365 Business Central or an SAP integration — we implement cancellation processes through middleware so that every booking entry in the ERP unambiguously references the original invoice.
In practice the order is crucial: the ZUGFeRD document is first produced in the shop, validated and signed there, then sent to the customer — and only then handed over to accounting. Reversing the order (booking in accounting first, producing the document second) risks divergences between the dispatched document and the booked version. These divergences are typical pitfalls during GoBD audits because the auditor usually demands that the document the customer received matches the booking document. Good integrations solve this through an event-bus architecture in which the ZUGFeRD XML is the single source of truth for invoice, cancellation and correction.
Validation and verification tools
Technical verification of a ZUGFeRD cancellation invoice or correction typically uses three validation layers: schema validation against UN/CEFACT CII, Schematron rules in line with EN 16931 and the validator configuration published by KoSIT (KoSIT). Which concrete tool is used in a project depends on infrastructure and ERP — we deliberately remain neutral on tool selection and align with the requirements of the accounting system and the recipient. More important than the tool question is that every outgoing e-invoice passes through a validation pipeline before being sent and that validation results are archived in an audit-proof way, analogous to the GoBD requirements profile. For shop operators we recommend integrating validation into the Shopware deployment pipeline so that validation takes place both at code level and in live operation.
For cancellations and corrections in particular, the KoSIT Schematron rules are strict: missing BG-3 references, implausible summary fields or inconsistent tax categories are reliably flagged as Fatal or Error messages (KoSIT). In our projects we set up the validation pipeline so that these severity classes block dispatch, while warnings are logged but not blocked. This prevents shop documents from being rejected by recipient systems and causing manual rework downstream — a scenario that in a B2B context quickly leads to payment delays and disputes over early-payment discounts.
Implementation roadmap until 2028
- By Q2 2026: current-state analysis — which document types does the shop currently produce (PDF, ZUGFeRD 1.x, XRechnung)? Inventory of all cancellation cases in the past 12 months
- Q3 2026: ZUGFeRD 2.3 upgrade — migration to the EN-16931-conform format, adjust Shopware templates for 380/381/384
- Q4 2026: workflow harmonisation — connect returns and withdrawal events to document generation (see PIM strategy)
- Q1 2027: sending pipeline — automated dispatch to customers and DATEV / ERP, validation before every send
- By 2027-01-01: 800,000 EUR threshold — anyone above must be able to send e-invoices (BMF)
- By 2028-01-01: send obligation without exception — all B2B transactions in the shop fully migrated to e-invoicing (BMF)
This article is based on: BMF circular dated 2024-10-15 on the implementation of the e-invoicing obligation, Bitkom ICT market forecast 2026, FeRD/AWV ZUGFeRD 2.3 (published 2024-09-18), KoSIT validator and BT-3 specifications, EN 16931 (European norm for electronic invoicing), E-Rechnung-Bund FAQ for the practical application of the codes, Shopware community documentation, GoBD (BMF principles on proper accounting), AWV (working group for economic administration), DATEV format definitions and IHK notes on the implementation of the Growth Opportunities Act. All information without guarantee — in specific cases we recommend consulting tax advisors and tax authorities.
Cancellation discipline as a compliance foundation
With the 2025/2027/2028 deadlines, the handling of cancellations, credit notes and corrections becomes a core element of every e-commerce workflow. Separating the three codes 380/381/384 cleanly, setting BG-3 references correctly and respecting GoBD immutability reduces the risk of queries from the tax authorities and creates a solid basis for resilient accounting automation. The XICTRON ZUGFeRD consulting supports shops with analysis, template adaptation and integration — from Shopware 6 through to the ERP connection.
Setting up the cancellation workflow cleanly early pays off twice: the technical foundation carries the upcoming 2027 and 2028 deadlines, and accounting gains time because returns, withdrawals and partial refunds no longer have to be reworked manually. Especially in Shopware projects with DATEV or ERP connections, clean handling of the BT-3 codes 381 and 384 is the lever that turns a pure compliance exercise into a genuine efficiency upgrade — while at the same time increasing audit reliability under GoBD (GoBD).
Usually code 381 (credit note / cancellation) is used when an invoice is fully reversed. Amounts are stated as positive — the minus sign is implied by the code (E-Rechnung-Bund FAQ). For partial corrections, code 384 is typically used; the concrete classification should be aligned with your tax advisor on a case-by-case basis.
Yes — as a rule, the KoSIT validation requires the BG-3 Preceding Invoice Reference with BT-25 (number of the preceding invoice) as a required field for code 384. If the invoice number is not unique, BT-26 (date) typically becomes de facto required as well (KoSIT).
According to § 14 (2) sent. 5 UStG, the obligation typically also extends to credit notes — which usually includes commercial cancellation documents in a shop context (BMF). Cancellation invoices are therefore generally produced in ZUGFeRD from 2.0.1 or XRechnung.
Under the GoBD principles this is typically not permitted — an invoice is considered fixed after dispatch (GoBD). The correct path is usually a cancellation invoice (code 381) followed by a re-issue or corrected invoice (code 384). Shopware 6 typically supports this workflow directly from the administration (Shopware).
The commercial credit note is typically a cancellation or correction document for an existing invoice. The credit note under § 14 (2) UStG, by contrast, is a billing document issued by the recipient of the service and can, in exceptional cases, trigger a § 14c tax liability (BMF). Only the latter is a credit note in the strict VAT sense — in everyday ZUGFeRD practice, the commercial variant typically dominates.
For the current legal situation, ZUGFeRD from version 2.0.1 is typically required; the current release 2.3 (2024-09-18) is EN-16931-conform and backwards-compatible with earlier profiles (FeRD/AWV). Shops setting up new integrations typically start directly with 2.3 and choose the profile to match their ERP and DATEV integration.