Self-billed invoice
Self-billing under § 14(2) of the German VAT Act: the recipient of the supply issues the document, not the supplier. Two line items, two tax rates, no charges or allowances – and as the only difference from an ordinary commercial invoice, document type 389.
The basis is the official sample invoice
E10_01_Gutschrift from the Factur-X / ZUGFeRD
documentation (FeRD sample package, ZUGFeRD 2.5.0). The code below
produces exactly that document, field by field and in the same order.
Some links on this page lead into the in-depth documentation in the customer area and require a sign-in.
Two things called “Gutschrift”
The German word carries two entirely different meanings, and confusing them is the most common mistake in this area:
| Self-billing (389) | Credit note (381) | |
|---|---|---|
| FactoorSharp | InvoiceType.SelfBilledInvoice |
InvoiceType.CreditNote |
| Who issues it? | The recipient of the supply bills on the supplier's behalf. | The supplier itself. |
| Amounts | positive – the document looks like an invoice | positive; the document mirrors the invoice as a whole |
| Legal basis | § 14(2) German VAT Act (self-billed invoice) | correction of a receivable |
| This page | covers this case | see correction invoice (type 384) for the distinction |
In self-billing all amounts stay positive. Setting negative quantities here because “Gutschrift” sounds like a reversal produces a document that is wrong in business terms. Negative amounts belong in the correction invoice.
COMFORT profile instead of EXTENDED
Unlike the other examples on these pages, this document sits in the
Profile.Comfort profile – guideline ID
urn:cen.eu:en16931:2017, the pure EN 16931 profile without
extensions. That is not an oversight in the reference but the statement that
this business case gets by without EXTENDED fields.
Consequently, every field that the extended goods invoice demonstrates is absent here: document name (BT-X-2), test indicator, packaging details (BT-X-9) and the extended tax bases. Setting them would not be an error – the writer would silently discard them in the COMFORT profile.
1. Document header
Number, date and currency as in any invoice. The only line that makes this a
self-billed document is invoice.Type.
2. Free-text notes
Four notes in ram:IncludedNote (BG-1). The first comes without a
subjectCode, two carry REG for regulatory information,
the last ACB for the format identification.
3. Seller with two tax registrations
AddSellerTaxRegistration can be called more than once. Here the
national tax number (FC, BT-32) comes first, then the VAT ID
(VA, BT-31). The order in the XML follows the order of the calls.
4. Buyer – with a tax number of its own
This is where self-billing shows up in the data model: because the recipient of the supply issues the document, it carries a VAT ID as well (BT-48). On an ordinary commercial invoice that field usually stays empty.
5. Document lines
Two line items (BG-25) without any item discount. Gross and net price are
therefore identical – the reference still writes both elements. Note that
both lines sit in the same tax category S and differ only in the
rate: 19 % for office supplies, 7 % for food.
6. Payment means
SEPA credit transfer (type code 58) and the payee's account. Other payment means and their fields are described under loading and saving.
7. VAT breakdown
Without document-level charges and allowances the basis amount is simply the sum
of the matching lines – no allowanceChargeBasisAmount, no
correction arithmetic:
| Field | 7 % (line 2) | 19 % (line 1) |
|---|---|---|
basisAmount |
275.00 | 198.00 |
taxAmount |
275.00 × 7 % = 19.25 | 198.00 × 19 % = 37.62 |
The column order is not a slip: the reference lists 7 % before
19 %, so not in the order of the lines. FactoorSharp emits the
tax groups in the order of the AddApplicableTradeTax calls and
does not sort them afterwards. If you want to match the reference file
character for character, order the calls accordingly.
8. Payment terms
A due date only, no early payment discount. That description is
null here is deliberate: the writer then does not emit
ram:Description at all rather than writing an empty element.
9. Document totals
| BT code | Parameter | Calculation |
|---|---|---|
| BT-106 | lineTotalAmount |
198.00 + 275.00 = 473.00 |
| BT-107 / BT-108 | allowanceTotalAmount / chargeTotalAmount |
0.00 – no charges or allowances |
| BT-109 | taxBasisAmount |
473.00 |
| BT-110 | taxTotalAmount |
19.25 + 37.62 = 56.87 |
| BT-112 | grandTotalAmount |
473.00 + 56.87 = 529.87 |
| BT-115 | duePayableAmount |
529.87 − 0.00 = 529.87 |
10. Saving
Here it is Profile.Comfort instead of Profile.Extended
– the only difference from the other examples at this point:
11. Cross-check
The generated file has to have the same tree structure as
E10_01_Gutschrift.xml from the FeRD sample package. Numbers are
compared numerically, so that 9.90 and 9.9000 count as
equal.
Whether the document also complies with the rule set is something you check either in the browser or straight from your code. For a human look at the document, the visualizer renders a readable version:
That is a plain rendition, not a legal document and not a hybrid ZUGFeRD PDF – details under visualization.