Correction invoice
The correction of an over-billed goods delivery: document type 384, all amounts negative, the unit prices positive. Built up step by step, with an eye on the places where a correction differs from a credit note.
The basis is the official sample invoice
X14_01_Rechnungskorrektur from the Factur-X / ZUGFeRD
documentation (FeRD sample package, ZUGFeRD 2.5.0, EXTENDED profile).
The code below produces exactly that document, field by field and in the
same order.
Correction or credit note?
That is the question most of the time goes into, and it decides every sign in the document. Both kinds of document reduce a receivable, but they do so in opposite ways:
| Correction invoice (384) | Credit note (381) | |
|---|---|---|
| FactoorSharp | InvoiceType.Correction |
InvoiceType.CreditNote |
| Quantities (BT-129) | negative | positive |
| Unit prices (BT-146 / BT-148) | positive | positive |
| Totals, taxes, discounts | negative | positive |
| Reading | The document corrects the original invoice by a difference. | The document mirrors the original invoice as a whole. |
The sign belongs in the quantity, not in the price. A negative unit price with a positive quantity yields the same line total arithmetically, but it is unsound in business terms and many recipients will notice. The reference does it the other way round, and so does this page.
The sections below build on one another and belong to one program. If you are new to FactoorSharp, start with Getting started instead – here the focus is on what makes the correction special. For every BT and BG code, the matching XML element is in the Factur-X reference.
1. Invoice header
Besides number, date and currency, two things stand out: the document type and the business process (BT-23), which this example sets unlike the goods invoice.
2. Free-text notes
The same kinds of note as in the goods invoice, but in a different order: the
AAK note with a content code comes first here. Since the
cross-check against the reference also compares the order, that is not a detail
but a requirement.
Note texts, product names and discount reasons stay in German throughout this page: they are the payload of the official reference document, and translating them would break the comparison with it.
3. Seller and buyer
Unchanged compared to a normal invoice – a correction does not swap the roles. The seller stays the seller, even when money flows back.
4. Document references
This is where it becomes visible what the correction refers to. Two additional document references (BT-18 / BG-24) with type code 130 carry the complaint process and the original invoice number.
For the reference to the corrected invoice there is also a specialised
element, ram:InvoiceReferencedDocument (BT-25/BT-26). The FeRD
reference does not use it here, so it does not appear in this code either
– but if you are not bound to the template, it is the more precise
option.
5. Ship-to party and invoicee
The differing recipients stay exactly as they were on the original invoice.
6. Invoice lines
This is where the actual correction sits: five bottles and two packs go back. The unit prices stay positive, the quantities turn negative, and that produces the negative line totals.
The item discounts from the original invoice (BT-147) stay positive as well. They are part of the price, not an amount on the invoice: 1.50 − 0.03 − 0.02 = 1.45, and only the negative quantity flips the result.
7. Document-level invoice discounts
The discounts turn around with everything else: a discount on a reversal is a reclaim, so both the basis amount and the amount are negative. As in any invoice with mixed tax rates, each discount needs its own entry per rate – two discounts become four calls.
8. VAT breakdown
The arithmetic is the same as in any invoice, only with inverted signs. The one
point that trips up readers: a negative discount raises the basis
amount again, which is why allowanceChargeBasisAmount is positive
here.
| Field | 19 % (line 1) | 7 % (line 2) |
|---|---|---|
lineTotalBasisAmount |
−5.00 | −2.90 |
allowanceChargeBasisAmount |
−(−0.10) − (−0.05) = +0.15 | −(−0.06) − (−0.02) = +0.08 |
basisAmount |
−5.00 + 0.15 = −4.85 | −2.90 + 0.08 = −2.82 |
taxAmount |
−4.85 × 19 % = −0.9215 → −0.92 | −2.82 × 7 % = −0.1974 → −0.20 |
9. Document totals
At the end there is a negative payable amount – that is the hallmark of a correction, and for the recipient the statement that money is coming back.
| BT code | Parameter | Calculation |
|---|---|---|
| BT-106 | lineTotalAmount |
−5.00 + (−2.90) = −7.90 |
| BT-107 | allowanceTotalAmount |
−0.10 − 0.06 − 0.05 − 0.02 = −0.23 |
| BT-109 | taxBasisAmount |
−7.90 − (−0.23) = −7.67 |
| BT-110 | taxTotalAmount |
−0.92 + (−0.20) = −1.12 |
| BT-112 | grandTotalAmount |
−7.67 + (−1.12) = −8.79 |
| BT-115 | duePayableAmount |
−8.79 – the amount goes back to the customer |
10. Saving and checking
Saving works as for any EXTENDED document – version, profile and syntax belong together:
The result has to have the same tree structure as
X14_01_Rechnungskorrektur.xml from the FeRD sample package.
Whether the document also complies with the rule set is what the validator answers – in the browser or straight from your code. A human-readable rendition is produced by the visualizer. Both, and the detailed documentation for them, live in the customer area; how to get there is covered under Getting started.