Skip to content
Fakturnaut
Log inTry 30 daysTry free

Self-billing (Gutschriften)

With self-billing, your platform settles your partners' supplies itself, as their recipient, instead of waiting for their invoices. An example is a charging network that pays the hosts of its charge points every month. Fakturnaut creates each self-billed invoice (Gutschrift) as a validated XRechnung or ZUGFeRD PDF, can send it by e-mail, and records objection and acceptance.

Self-billing is in preparation. Until it is enabled for your account, its endpoints answer 404 self-billing.disabled. Live keys need a plan with self-billing (402 self-billing.plan-not-included). Test keys work on every plan, in the sandbox.

This page is not tax advice. Every tax statement names its source. Whether and how you use self-billing is for you and your tax adviser to decide.

Roles

A Gutschrift is an invoice issued by the recipient of the supply (§ 14(2) sentence 5 UStG). In the e-invoice:

RoleWhoIn the e-invoice
Issuer (recipient of the supply)your seller (issuerId, an entry of /sellers)buyer, BG-7
Supplieryour partner (/suppliers)seller, BG-4

Fakturnaut sets both parties, the number (GS-<year>-…), type code 389 and the word "Gutschrift" required by § 14(4) sentence 1 no. 10 UStG.

Suppliers by your own ID

Keep your partners in sync by your own ID (externalId). PUT creates a supplier (201) or updates it (200); an unchanged body changes nothing.

curl -s -X PUT "$BASE/suppliers/by-external-id/host-hotel-muster" -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' -d '{
    "name": "Hotel Muster KG", "entrepreneur": true, "vatId": "DE812345673", "vatTreatment": "standard",
    "address": {"street": "Seestraße 5", "city": "Berlin", "postCode": "10115", "country": "DE"},
    "contact": {"name": "Erika Muster", "phone": "+49 30 123456", "email": "buchhaltung@hotel-muster.example"},
    "invoiceEmail": "gutschriften@hotel-muster.example", "iban": "DE89370400440532013000"}'
  • Businesses only. entrepreneur is required, and false is refused (self-billing.supplier-not-entrepreneur). Self-billing requires the supplier to be a business (§ 14(2) sentence 5 UStG), so a payout to a private person is no Gutschrift.
  • A VAT ID or a tax number is required.
  • smallBusiness: true (Kleinunternehmer) goes with vatTreatment: "small-business". All other suppliers have standard or reverse-charge.
  • Responses show the IBAN and the tax number masked (…3000).
  • Every change fires the event supplier.updated. It names the changed fields, never their values.

The agreement before the first Gutschrift

A Gutschrift only counts as an invoice if both parties agreed on self-billing beforehand (§ 14(2) sentence 5 UStG). Record that agreement. attestation: true confirms the text self-billing-agreement-v1.

curl -s -X POST "$BASE/suppliers/$SUPPLIER/agreements" -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' -d '{"sellerId": "'"$SELLER"'", "kind": "terms-clause",
    "concludedOn": "2026-01-01", "validFrom": "2026-01-01", "attestation": true}'

Without an agreement valid on the issue date, the Gutschrift is refused. Upload a copy of the agreement (PDF, PNG or JPEG, at most 10 MB) with POST …/agreements/{id}/document. When the agreement ends, end it with POST …/agreements/{id}/revocation.

Issuing a Gutschrift

Every call needs an Idempotency-Key. externalReference is your payout ID and is unique per key mode.

curl -s -X POST "$BASE/self-billed-invoices" -H "Authorization: Bearer $KEY" \
  -H 'Idempotency-Key: payout-2026-10-host-hotel-muster' -H 'Content-Type: application/json' -d '{
    "issuerId": "'"$SELLER"'", "supplierExternalId": "host-hotel-muster",
    "externalReference": "payout-2026-10-host-hotel-muster", "delivery": "email", "formats": ["zugferd"],
    "content": {"servicePeriod": {"start": "2026-10-01", "end": "2026-10-31"}, "dueDate": "2026-11-15",
      "lines": [{"name": "Ladestrom Oktober 2026", "quantity": 1240, "unitCode": "KWH", "netPrice": 0.30,
                 "vatCategory": "S", "vatRate": 19}]}}'

Formats. zugferd, xrechnung-ubl or xrechnung-cii. Without formats, the supplier's preferredFormat applies, otherwise zugferd. Every format passes the official validation before it is issued. GET /self-billed-invoices/{id}/document?format=… downloads a file, and …/report checks it again.

Delivery.

  • delivery: "email" sends the Gutschrift to the supplier's invoiceEmail. This needs your seller to be verified.
  • none (the default) means you deliver it yourself; record that with POST …/delivery-marks.

A Gutschrift never goes as an ordinary XRechnung over Peppol: the supplier's system would book it as a purchase invoice. Delivery as Peppol BIS Self-Billing 3.0 (delivery: "peppol") is being prepared. Until it is switched on, peppol answers 422 self-billing.channel-not-supported. Once it is on, the Gutschrift goes to the supplier's peppolId. A supplier that is not registered for self-billing documents on Peppol gets it at its invoiceEmail. In the same way, your own sellers that receive Peppol documents through us will be able to receive Gutschriften from their customers (PUT /sellers/{id}/peppol/self-billing).

Monthly payout runs

A batch takes up to 1,000 Gutschriften and 1 MB. It runs in the background, and a failed item never stops the others. Every item needs an externalReference. An item sent again with the same externalReference and content, even in a new batch, answers the Gutschrift issued before; with other content it fails (self-billing.external-reference-taken).

curl -s -X POST "$BASE/self-billed-invoices/batches" -H "Authorization: Bearer $KEY" \
  -H 'Idempotency-Key: payout-2026-10' -H 'Content-Type: application/json' -d @payout-batch.json   # 202
curl -s "$BASE/self-billed-invoices/batches/$BATCH" -H "Authorization: Bearer $KEY"

When everything is processed, the event self_billing.batch.completed reports the result. A runnable example with curl, Node and each SDK is in the repository under examples/self-billing: a run for three hosts, at 19 %, with a Kleinunternehmer and with reverse charge.

VAT: Kleinunternehmer and § 13b UStG

  • Kleinunternehmer: the lines carry vatCategory: "E" at 0 %. Fakturnaut adds the note on § 19 UStG. Lines with VAT are refused, because whoever shows VAT without being entitled to can owe it under § 14c(2) UStG.
  • Reverse charge: the lines carry vatCategory: "AE" at 0 %. Fakturnaut adds "Steuerschuldnerschaft des Leistungsempfängers" (§ 14a(5) UStG). For electricity from a supplier established in Germany, this applies only if the supplier and the recipient are both resellers of electricity (§ 13b(2) no. 5 letter b and (5) sentence 4 UStG; sections 3g.1 and 13b.3a UStAE). Whether that is the case is for you and your tax adviser to decide.

Fakturnaut checks that the VAT category and the supplier match. Fakturnaut makes no tax assessment.

Objection and acceptance, corrections and cancellations

The supplier can object to the Gutschrift. With the objection it loses its effect as an invoice (§ 14(2) sentence 6 UStG). Record the objection or acceptance as you received it. Fakturnaut only records it; nothing happens automatically.

curl -s -X POST "$BASE/self-billed-invoices/$ID/objection" -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' -d '{"receivedOn": "2026-11-03", "channel": "letter", "reason": "Menge falsch"}'
curl -s -X POST "$BASE/self-billed-invoices/$ID/acceptance" -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' -d '{"channel": "email"}'
  • Correction: POST …/corrections states the change; a negative quantity reduces.
  • Cancellation: POST …/cancellation reverses the Gutschrift and its corrections.
  • Both are Gutschriften of their own, with type code 389 and a reference to the original. Both need an Idempotency-Key.

Events: self_billed_invoice.issued, .objected and .accepted. They carry the date and the channel, never the reason (webhooks).

Billing and sandbox

  • Every Gutschrift, correction and cancellation counts as one document of your plan.
  • A test key creates test Gutschriften. They are marked as test, use their own number series, are never billed and are deleted after 30 days.
  • Suppliers and agreements of the test mode are separate from your live data.

All endpoints are in the API reference under "Self-billing".

Sources