FAQ

Find answers to 9 frequently asked questions about E-INVOICE, organized by topic.

Germany (2)

E-INVOIC DE - Which VAT rates and exemptions can be used in Germany?

The codes your System accepts are always available through the API: GET /systems/{system_id} returns them in content.vat_exemptions and content.vat_rates, each with a short description and its legal basis.

This article lists the VAT treatments available in Germany when using E-INVOICE DE for sending e-invoices.

VAT_RATE

vat.code	vat.percentage	Typical use cases
STANDARD	19%	Default rate for every taxable supply without a reduced rate (§ 12 Abs. 1 UStG)
REDUCED_1	7%	Goods listed in Anlage 2 UStG and the listed services (§ 12 Abs. 2 UStG)
REDUCED_2	0%	Supply and installation of PV systems, incl. storage, on or near residential buildings (§ 12 Abs. 3 UStG)
REDUCED_3	7.8%	Flat-rate scheme for farmers, agricultural products (§ 24 Abs. 1 Nr. 3 UStG)
REDUCED_4	5.5%	Flat-rate scheme, forestry products (§ 24 Abs. 1 Nr. 1 UStG)
REDUCED_5	16%	Historic: only for corrections of supplies made 1 Jul – 31 Dec 2020
REDUCED_6	5%	Historic: supplies made 1 Jul – 31 Dec 2020
Note: vat.code and vat.percentage must match. A request with a code and a percentage that don’t belong together fails.

VAT_EXEMPTION

vat.code	Description
CAUSE_1	The seller is a small business (§ 19 UStG)
CAUSE_2	Goods go to a business in another EU country (§ 4 Nr. 1b, § 6a UStG)
CAUSE_3	Goods leave the EU (§ 4 Nr. 1a, § 6 UStG)
CAUSE_4	Rent for land or buildings (§ 4 Nr. 12 UStG)
CAUSE_5	Financial or insurance services (§ 4 Nr. 8, 10, 11 UStG)
CAUSE_6	Medical treatment by doctors and health professions (§ 4 Nr. 14 Buchst. a UStG)
CAUSE_7	Education and training by schools and institutions (§ 4 Nr. 21 Buchst. a/b, § 4 Nr. 22 Buchst. a UStG)
CAUSE_8	Used goods sold under the margin scheme (§ 25a UStG, § 14a Abs. 6 UStG)
CAUSE_9	Costs passed on in the customer’s name, durchlaufende Posten (§ 10 Abs. 1 UStG)
CAUSE_10	Services linked to an export or transit of goods, mainly transport (§ 4 Nr. 3 Buchst. a UStG)
CAUSE_11	Services linked to an import, where the cost is part of the import VAT base (§ 4 Nr. 3 Buchst. a UStG)
CAUSE_12	Supplies for sea shipping or international aviation (§ 4 Nr. 2, § 8 UStG)
CAUSE_13	Brokerage of exempt cross-border supplies: export, transport, supplies in third countries (§ 4 Nr. 5 UStG)
CAUSE_14	Works of art under the margin scheme (§ 25a UStG, § 14a Abs. 6 UStG)
CAUSE_15	Collectors’ items and antiques under the margin scheme (§ 25a UStG, § 14a Abs. 6 UStG)
CAUSE_16	Travel services under the margin scheme for travel agents, bought-in services in the EU (§ 25 Abs. 1 UStG, § 14a Abs. 6 UStG)
CAUSE_17	Travel services whose bought-in services are performed outside the EU (§ 25 Abs. 2 UStG)
CAUSE_18	Supplies to NATO forces, diplomatic missions, international bodies or EU armed forces in another EU country (§ 4 Nr. 7 UStG)
CAUSE_19	Supplies to NATO forces stationed in Germany via their official procurement office (Art. 67 Abs. 3 ZA-NTS)
CAUSE_20	Sale of land or buildings without opting for VAT (§ 4 Nr. 9 Buchst. a UStG)
CAUSE_21	Hospital and closely related medical care by approved facilities (§ 4 Nr. 14 Buchst. b UStG)
CAUSE_22	Universal postal services, not individually negotiated rates (§ 4 Nr. 11b UStG)
CAUSE_23	Care, welfare and social security services (§ 4 Nr. 15, 15a–c, 16, 18 UStG)
CAUSE_24	Childcare and youth welfare, including related meals and accommodation (§ 4 Nr. 23, 25 UStG)
CAUSE_25	School or university lessons by private tutors (§ 4 Nr. 21 Buchst. c UStG)
CAUSE_26	Sports events and courses by non-profit bodies, paid as participant fees (§ 4 Nr. 22 Buchst. b UStG)
CAUSE_27	Cultural services by public or state-certified institutions (§ 4 Nr. 20 UStG)
CAUSE_28	Cost-sharing groups charging members at exact cost (§ 4 Nr. 29 UStG)
CAUSE_29	Supply of human organs, blood or breast milk (§ 4 Nr. 17 Buchst. a UStG)
CAUSE_30	Patient transport in specially equipped vehicles (§ 4 Nr. 17 Buchst. b UStG)
CAUSE_31	Any other exemption under § 4 UStG. The reason must name the paragraph
NOT_SUBJECT	A real supply whose place of supply is outside Germany, nicht im Inland steuerbar (§ 3a, § 3 Abs. 7 UStG)
NOT_TAXABLE	No supply for VAT purposes at all, nicht steuerbar (§ 3 Abs. 15, § 1 Abs. 1a UStG)
NOT_SUBJECT can’t be sent as an e-invoice yet.

Note: vat.reason is optional. If you don’t send it, a standard exemption text for the code is included in the e-invoice; if you send it, your text is used instead (up to 128 characters).

Exception: CAUSE_31 always requires a vat.reason that names the paragraph of § 4 UStG.

Which VAT treatment applies to a supply is a tax decision. If in doubt, check with your tax advisor.

E-INVOICE DE - How to detect and handle failed invoices

Sending invoices

While using E-INVOICE DE, a failed **outgoing e-invoice **can be reported in three places, depending on where it failed. Check them in this order:

• the API response

• the TRANSACTION::INVOICE Record

• the E_INVOICE::TRANSMISSION Record

Received invoices are reported differently. See Receiving invoices at the end.

A TRANSACTION::INVOICE in state COMPLETED does not by itself mean the invoice was sent. Always check its logs too. Log entries with "severity": "ERROR" mean the invoice was not processed. WARNING entries are informational only.

 

Step 1: Check the API response

If the request doesn’t match the API schema, for example a field with the wrong format or an empty value, it’s rejected with HTTP 400 (E_BAD_REQUEST). The message names the field. No Record is created. Fix the request and send it again.

Example message:

"message": "request validation failed: Error at \"/content/operation\": ... Error at \"/document/references/buyer\": doesn't match schema due to: minimum string length is 1"

 

Step 2: Check the TRANSACTION::INVOICE Record

If the request is accepted (HTTP 200), the invoice content is checked against the rules of the chosen format. If a rule is not met, the Record still shows COMPLETED, but content.logs contains an ERROR entry and content.used_in is missing. The invoice was not generated or sent.

{
  "content": {
    "type": "TRANSACTION::INVOICE",
    "state": "COMPLETED",
    "mode": "FINISHED",
    "logs": [
      {
        "message": "invalid gobl invoice: ordering is required (BR-DE-15)",
        "severity": "ERROR"
      }
    ]
  }
}

 

Step 3: Check the E_INVOICE::TRANSMISSION Record

If there is no ERROR log, retrieve the transmission Record using content.used_in.id:

GET /records/{used_in.id}

• **COMPLETED**: the e-invoice was handed over for delivery. For email, there is no confirmation that it reached the recipient’s inbox, and later bounces are not reported.

• **FAILED**: the e-invoice could not be generated or delivered, and it did not reach the buyer. The reason is in content.logs.

 

Common error messages

Message	What to do
ordering is required (BR-DE-15)	XRechnung requires document.references.buyer (1–32 characters). ZUGFeRD doesn’t.
business recipient identification is not a valid VAT identification	Use identification.type: VAT for BUSINESS recipients.
receiver does not support document type	The Peppol recipient can’t receive XRechnung. Send to them by email instead.

How to send a failed invoice again

An invoice that failed in step 2 or 3 was not issued and did not reach the buyer. Don’t create a credit note (CORRECTION) for it. Send it again instead:

• Fix the cause shown in the ERROR log, for example add the missing field or correct the recipient’s email address. Change nothing else.

• Create a new INTENTION::TRANSACTION.

• Create a new TRANSACTION::INVOICE with the corrected payload and a new idempotency key. Keep the same invoice number, and if you set document.issued_at, keep its original value.

Warning: When sending a failed invoice again, always keep its original invoice number. A new number would turn the resend into a second, separate invoice. A credit note (CORRECTION) is only for an invoice that reached the buyer and whose content is wrong.

 

Receiving invoices

Incoming invoices are received over Peppol as Peppol BIS Billing 3.0 (see Receiving invoices for more details). Other document types, including XRechnung, are rejected by the Peppol network before they reach fiskaly, so no Record is created for them.

Each received invoice is stored as an E_INVOICE::RECEPTION Record in state COMPLETED. This confirms receipt, not that the content is correct: problems in a received invoice are not flagged on the Record. You can retrieve the XML of each received invoice for your own processing with:

GET /records/{reception_record_id}?compliance-artifact

 

There’s no webhook for received invoices yet. Call listRecords regularly, filtered for E_INVOICE::RECEPTION, and keep track of the Records you have already processed.

For more on Record states and logs, see How to check the status of an e-invoice?.

General (3)

What is a Peppol identifier and which scheme code should I use?

When sending an e-invoice over the Peppol network, you address it to the recipient using their Peppol identifier. This article explains how it’s structured and how to get it right.

 

What it is

A Peppol identifier is an address on the Peppol network, not a tax number. It has two parts:

<scheme>:<value>

The scheme is a four-digit code saying which registry the value comes from. The value is the number from that registry.

 

Where it goes

Set it on the recipient with type: "PEPPOL"

"recipients": [
  {
    "type": "BUSINESS",
    "invoicing": {
      "type": "PEPPOL",
      "identifier": "0208:0741778202"
    }
  }
]

 

Supply the complete identifier, including the scheme code. There’s no separate scheme field — it’s one string, written exactly as the recipient is registered.

Which scheme to use

Country	Scheme	Registry	Example
Belgium	0208	Enterprise number (KBO/BCE)	0208:0741778202
Belgium	9925	VAT	9925:BE0741778202
Germany	9930	VAT	9930:DE123456789
Note that the value format differs by scheme: 0208 takes the enterprise number as the register writes it, with no prefix, while the VAT schemes take the VAT number with its country prefix. Both are correct — they point at different registries.

A Belgian company may be reachable under either 0208 or 9925. Use the one the recipient is actually registered under — a correctly formatted identifier under the wrong scheme won’t reach them.

 

How to get the recipient’s identifier

Ask the recipient, or their e-invoicing provider. You can also search directory.peppol.eu, but listing there is optional — a business can be reachable on Peppol without appearing in it.

 

Error: “No matching participant found”

The identifier isn’t registered on the Peppol network. This is not a formatting error — a valid, correctly written identifier returns this if the business behind it was never onboarded to Peppol.

• Confirm the recipient is on Peppol at all. A private company in a country without a mandate often isn’t. If so, they must register with a Peppol access point first — fiskaly cannot do this for them.

• If they are, try the other scheme for their country.

Which token do I need and when do I need to create one?

The integration guide describes two separate token creation steps (Step 4 and Step 7). This can be confusing — especially if your organization is already set up and you just want to send e-invoices. Here’s what each token is for and which one you actually need.

The two tokens explained

The API is split into two groups of endpoints: Management and Operation. Each group requires a token scoped to a different level.

Group-level token (Step 4) — for Management

This token is created using the API Key generated in the HUB at the Group level. It authenticates you for the Management endpoints:

• POST /organizations — create an Organization UNIT

• POST /subjects — create a new API Key scoped to a UNIT

• GET /subjects — list existing API Keys

You only need this token during the initial setup when creating your Organization UNIT and generating the UNIT-scoped API Key. Once those resources exist, you don’t need to create this token again unless you’re onboarding a new UNIT.

UNIT-scoped token (Step 7) — for Operation

This token is created using the API Key that was generated in Step 6 (the one scoped to your Organization UNIT via the X-Scope-Identifier header). It authenticates you for all Operation endpoints:

• POST /taxpayers — create and manage taxpayers

• POST /systems — create and manage systems

• POST /records — create records (intentions, transactions, uploads)

• GET /records/{record_id} — retrieve record status

• All other taxpayer, location, system, record, and file endpoints

Quick reference

I want to…	Token needed	How to create it
Set up a new Organization UNIT	Group-level	POST /tokens with HUB API Key
Create a new UNIT-scoped API Key	Group-level	POST /tokens with HUB API Key
Create/commission a Taxpayer	UNIT-scoped	POST /tokens with UNIT API Key
Create/commission a System	UNIT-scoped	POST /tokens with UNIT API Key
Upload Proof of Ownership	UNIT-scoped	POST /tokens with UNIT API Key
Send e-invoices (day-to-day)	UNIT-scoped	POST /tokens with UNIT API Key
Issue a credit note	UNIT-scoped	POST /tokens with UNIT API Key

How to check the status of an e-invoice?

When creating an invoice Record (TRANSACTION::INVOICE), a transmission Record (E_INVOICE::TRANSMISSION) is also created alongside to track the delivery of the e-invoice. 

Note: A TRANSACTION::INVOICE in COMPLETED state and FINISHED mode does not necessarily mean the e-invoice was accepted. Diagnostic logs on both Records should be checked to identify any issues. For E-INVOICE DE  and BE, the TRANSACTION::INVOICE Record reaches the COMPLETED state as soon as the e-invoice is accepted for transmission, while the E_INVOICE::TRANSMISSION Record shows the actual delivery status. For this reason, the states of the two Records can differ. For E-INVOICE IT, the states of the two Records are always aligned.

Step 1: Retrieve the TRANSACTION::INVOICE Record

When creating a TRANSACTION::INVOICE, save the record id from the API response. Then retrieve it using:

GET /records/{{record_id}}

In the response, check the content.logs field:

• If it contains entries with "severity": "ERROR", the invoice failed validation before any transmission was attempted. To resolve the issue, review the error message, correct the request payload accordingly, and create a new TRANSACTION::INVOICE Record with a new idempotency key, the same invoice number, date and content. 

• If content.logs contains no ERROR entries, validation passed and the e-invoice was submitted for transmission. Proceed to Step 2.

Step 2: Retrieve the E_INVOICE::TRANSMISSION Record

In the TRANSACTION::INVOICE response from Step 1, locate the content.used_in.id field. This is the ID of the E_INVOICE::TRANSMISSION Record. Retrieve it using:

GET /records/{{content.used_in.id}}

Check the content.logs field:

• If it contains ERROR entries, the e-invoice could not be delivered through the e-invoicing channel. The message field describes what went wrong. 

• If the error concerns the invoice content, correct the request payload accordingly and create a new TRANSACTION::INVOICE Record with a new idempotency key, the same invoice number, date and content.

• If the error indicates a network or infrastructure issue, retry after a short delay.  If the issue persists, contact fiskaly support.

• If content.logs contains no ERROR entries on both Records, the transmission may still be in progress. E-invoice delivery is handled asynchronously:

For DE and BE, it typically completes within seconds to minutes. 

• For IT, the response from SDI can take up to 5 days. 

If the e-invoice is still not delivered after several minutes for DE and BE, or after 5 days for IT, contact fiskaly support.

Reading a log entry

Each log entry contains the following fields:

Field	Description
severity	ERROR (a failure that prevented delivery) or WARNING (a non-fatal issue, the operation still proceeded).
message	A human-readable description of the issue.

Example

[
  {
    "message": "invalid Belgian VAT ID length '12'",
    "severity": "ERROR"
  }

 

Note: WARNING logs are informational and do not affect the transmission of the e-invoice.

Italy (3)

E-INVOICE IT - How to represent payments on an invoice

Payments are carried in payments[] on the invoice operation. The array accepts between 1 and 10 entries. Which fields you provide depends on whether the invoice has already been settled.

 

Payment already received

Select the payment type that applies — CASH, CARD, ONLINE, VOUCHER or OTHER — and provide details.amount.  Some types require additional fields:

Type	Additional required fields
CASH	—
CARD	number, kind
VOUCHER	number, kind
ONLINE	name
OTHER	— (name is optional)
Optionally, details can also carry date , discount and properties. The currency of the first payment in the array sets the currency of the whole invoice and  EUR is the only accepted value.

Payments of these types count as already settled — they reduce the amount the buyer still owes on the invoice. There are 2 possible scenarios:

• If they cover the invoice total, nothing further is needed.

• If they don’t, add an OUTSTANDING payment for the remainder; otherwise the invoice is rejected because the amounts don’t add up.

Payment still outstanding

Use payments[].type: "OUTSTANDING". payments[].concept is required and indicates whether the outstanding amount concerns a GOOD, a SERVICE, or an INVOICE. 

OUTSTANDING takes a details object: 

• details.amount is required and carries the amount still due.

• details.date is also required and sets the payment due date — an outstanding payment without a due date is rejected.

If you send more than one OUTSTANDING payment, only the first one is used. The others are ignored, and a warning is recorded on the invoice record.

• Payment instruction The instruction object is optional. Add it when the invoice should tell the buyer how to pay — for a bank transfer, it carries the IBAN the buyer should send the money to.

If you leave it out, the invoice is still accepted and transmitted. fiskaly then reports the payment method as a bank transfer, without any account details. So include an instruction when you want your account details on the invoice, or when the buyer is meant to pay some other way (by SEPA direct debit, for example).

When instruction is provided, instruction.type is CREDIT_TRANSFER or DIRECT_DEBIT. An instruction missing any of these fields is rejected:

 

CREDIT_TRANSFER requires type, account, name and payment_service_provider — all four. The IBAN goes in account, in ISO 13616 format (15–34 characters). payment_service_provider is the bank’s BIC/SWIFT code (e.g. BCITITMM) — a bank name is not accepted.

• DIRECT_DEBIT requires type, mandate_reference, creditor_id and debited_account, with the IBAN in debited_account. 

Note that creditor_id is an object rather than a string — { "type": "SEPA", "identifier": "IT05ZZZ12345678901" } — and the identifier is to match the SEPA creditor identifier format (9–35 characters), where the character following the three-letter business code is a digit.

Both variants also accept the optional fields text and properties. ** **Properties has a different shape depending on where it appears: on details it is an object of up to 16 entries whose values are strings of up to 64 characters, while on instruction it is a single string of up to 128 characters.

Note: instruction.type: “UNKNOWN” is not supported for Italy. It exists to allow text and properties without a credit transfer or direct debit, and is relevant for other E-INVOICE countries. Sending it for Italy returns a validation error requiring the it-sdi-payment-means extension.

 

Example of outstanding payment via bank transfer

{
  "payments": [
    {
      "type": "OUTSTANDING",
      "concept": "INVOICE",
      "details": {
        "amount": "122.00",
        "date": "2026-09-30"
      },
      "instruction": {
        "type": "CREDIT_TRANSFER",
        "account": "IT60X0542811101000000123456",
        "name": "Officina Rossi S.r.l.",
        "payment_service_provider": "BCITITMM"
      }
    }
  ]
}

 

Field	In the example
details.amount	The amount still due — not the invoice total
details.date	The payment due date — not the issue date
account	Your IBAN — the account the money arrives in
name	The holder of that account, i.e. you, the invoice issuer
payment_service_provider	The BIC/SWIFT code of your bank — not its name

Note: ModalitaPagamento is not a field you set. It is derived from the payment instruction on the outstanding payment, or defaulted to MP05 when no instruction is given. Bank transfer and SEPA direct debit are covered. Cheque and Riba are not currently supported — if you need them, contact fiskaly support so we can record the requirement.

 

Example of outstanding payment via SEPA direct debit

Only the instruction object differs from the bank transfer example above; type, concept and details are unchanged.

{
  "instruction": {
    "type": "DIRECT_DEBIT",
    "mandate_reference": "MANDATE-2026-0042",
    "creditor_id": {
      "type": "SEPA",
      "identifier": "IT05ZZZ12345678901"
    },
    "debited_account": "IT60X0542811101000000123456"
  }
}

Field	In this example
mandate_reference	Your reference for the SEPA mandate the buyer signed
creditor_id.identifier	Your SEPA creditor identifier — you collect the money
debited_account	The buyer’s IBAN — the account you debit

Note the direction: in a credit transfer the IBAN is yours and the buyer pushes the money; in a direct debit the IBAN is the buyer’s and you pull it.

E-INVOICE IT - Which document types can you emit?

This article explains which FatturaPA document types (TipoDocumento) fiskaly E-INVOICE produces for Italy. 

The document type is not a field in the invoice request. It is derived from the operation you use. The supported types are:

TRANSACTION::INVOICE = TD01 — Fattura (invoice)

TRANSACTION::CORRECTION = TD04 — Nota di credito (credit note)

Advance payments (fattura di acconto)

FatturaPA defines TD02 for advances, which E-INVOICE IT does not currently emit. An advance is issued as a TRANSACTION::INVOICE for the amount received, producing a TD01 that covers the partial amount. Since the document type does not itself indicate an advance, we recommend carrying that in the line description, for example Acconto su contratto/ordine n. X del GG/MM/AAAA.

A balance invoice is a new invoice rather than a correction, so the system can’t look up the advance invoice for you. Link it to the advance yourself using document.references.preceding_document, with the advance invoice’s number and issue date.

Note: The AdE Guida alla compilazione delle fatture elettroniche provides TD02 for this case. If your process requires the dedicated document type, or you are unsure how the advance and balance amounts should be split, please confirm the approach with your tax advisor before implementing.

E-INVOICE IT - Which VAT rates and exemptions can be used in Italy?

This article provides a detailed mapping of the VAT treatments applicable in Italy when using E-INVOICE IT for sending e-invoices.

VAT_RATE

vat.code	vat.percentage	Typical use cases
STANDARD	22%	Default rate for anything not expressly reduced
REDUCED_1	10%	Tourism/hospitality, restaurants, construction works, domestic energy, some foods and pharmaceuticals
REDUCED_2	5%	Certain social/care services, some essential goods, works of art
REDUCED_3	4%	Staple foods, books and newspapers, first homes, aids for the disabled

Note: Currently, the code is not cross-validated against the percentage. The applied VAT treatment is determined solely by the percentage field, not by the code field.  

VAT_EXEMPTION

Natura codes are the official exemption codes required by the Italian tax authority (Agenzia delle Entrate) for FatturaPA invoices, tied to specific articles of the Italian VAT law.

vat.code	Natura code	Description
CAUSE_1	N1	Excluded ex art. 15 DPR 633/72 (Escluse ex art. 15 DPR 633/72)
CAUSE_5	N2.1	Not subject to VAT under arts. 7–7-septies DPR 633/72 (Non soggette ad IVA ai sensi degli artt. da 7 a 7-septies del DPR 633/72)
CAUSE_6	N2.2	Not subject - other cases (Non soggette - altri casi)
CAUSE_7	N3.1	Not taxable - exportations (Non imponibili - esportazioni)
CAUSE_8	N3.2	Not taxable - intra-Community transfers (Non imponibili - cessioni intracomunitarie)
CAUSE_9	N3.3	Not taxable - transfers to San Marino (Non imponibili - cessioni verso San Marino)
CAUSE_10	N3.4	Not taxable - transactions treated as export supplies (Non imponibili - operazioni assimilate alle cessioni all’esportazione)
CAUSE_11	N3.5	Not taxable - declaration of intent (Non imponibili - a seguito di dichiarazioni d’intento)
CAUSE_12	N3.6	Not taxable - other, non-plafond-forming transactions (Non imponibili - altre operazioni che non concorrono alla formazione del plafond)
CAUSE_2	N4	Exempt (Esenti)
CAUSE_3	N5	Marginal scheme (Regime del margine)
CAUSE_13	N6.1	Reverse charge - transfer of scrap and other recyclable materials (Inversione contabile — cessione di rottami)
CAUSE_14	N6.2	Reverse charge - transfer of gold and silver (L. 7/2000), used jewelry to OPO (Inversione contabile - cessione di oro e argento ai sensi della legge 7/2000 nonché di oreficeria usata ad OPO)
CAUSE_15	N6.3	Reverse charge - subcontracting in the construction sector (Inversione contabile — subappalto nel settore edile)
CAUSE_16	N6.4	Reverse charge - transfer of buildings (Inversione contabile — cessione di fabbricati)
CAUSE_17	N6.5	Reverse charge - transfer of mobile phones (Inversione contabile — cessione di telefoni cellulari)
CAUSE_18	N6.6	Reverse charge - transfer of electronic products (Inversione contabile — cessione di prodotti elettronici)
CAUSE_19	N6.7	Reverse charge - provisions in the construction and related sectors (Inversione contabile — prestazioni comparto edile e settori connessi)
CAUSE_20	N6.8	Reverse charge - transactions in the energy sector (Inversione contabile — operazioni settore energetico)
CAUSE_21	N6.9	Reverse charge - other cases (Inversione contabile — altri casi)
CAUSE_22	N7	VAT paid in another EU country (IVA assolta in altro stato UE)

Note: VAT validation on the document only checks that totals.vat (amount, exclusive, inclusive) matches the amount recalculated from entries[]. Any discrepancy raises a non-blocking warning, as the transmitted document always uses the recalculated value, not the declared totals.vat.

Belgium (1)

E-INVOICE BE - What is the difference between tax_id_number and vat_id_number for Belgian taxpayers?

When creating a Belgian taxpayer via POST /taxpayers, the fiscalization object requires both a tax_id_number and a vat_id_number. These are two distinct identifiers that serve different purposes and are validated independently — even though for some Belgian companies the numeric value may be the same.

In all cases, provide only the numeric digits. Do not include dots, spaces, or any country prefix.

tax_id_number — KBO/BCE Enterprise Number

This is the company registration number issued by the Belgian Crossroads Bank for Enterprises (Kruispuntbank van Ondernemingen / Banque-Carrefour des Entreprises).

• Format: 9 or 10 digits

• Pattern: ^[01]?\d{9}$

• Example: 0123456789 or 123456789

vat_id_number — Belgian VAT Identification Number (VATIN)

This is the VAT registration number used for tax purposes.

• Format: Exactly 10 digits

• Pattern: ^[0-9]{10}$

• Example: 0123456789

Example: Belgian fiscalization block

 

JSON:

{
  "type": "BE",
  "tax_id_number": "0123456789",
  "vat_id_number": "0123456789",
  "credentials": {
    "type": "MYMINFIN"
  }
}

credentials.type must be set to MYMINFIN for Belgian taxpayers.

Common mistakes

Mistake	What happens
Including the BE prefix in vat_id_number (e.g. "BE0123456789")	Rejected — the pattern only allows digits
Swapping the two fields	May cause validation or transmission errors
Including dots or spaces (e.g. "0123.456.789")	Rejected — only digits are accepted
Providing a vat_id_number with fewer than 10 digits	Rejected — exactly 10 digits required