# NormAPI > An HTTP API that validates, generates and reads German e-invoices. Validation runs > the official KoSIT validator against the XRechnung rule set, so a result here is the > result the recipient will get. Generation emits XRechnung UBL, XRechnung CII and > hybrid ZUGFeRD PDFs, on our page or embedded in the caller’s own PDF. Parsing reads > an incoming XRechnung, ZUGFeRD or Factur-X back into the JSON generation takes. Rule set in use: v2026-08-31 (XRechnung 3.0.2), run by KoSIT validator 1.6.3. Validation and parsing are free and unmetered, including through the API; only generation is billed. Availability is measured from outside by UptimeRobot every five minutes, published as text on the status page below. Germany requires structured e-invoices from businesses over €800,000 turnover in January 2027 and from all businesses in January 2028. Receiving them has been mandatory since January 2025. Every page below exists in German as well. German is canonical at the site root (`/fehler/br-de-15`); English lives under `/en` (`/en/errors/br-de-15`). ## Product - [Validator](https://normapi.com/en/validator): Paste or upload an XRechnung or ZUGFeRD invoice and get the official KoSIT validation result; every business-rule finding comes with what the rule requires and how to fix it, in plain language. Below it, the invoice itself in readable form (also the XML inside a ZUGFeRD PDF), and the whole report prints or saves as a PDF. Free, no account. - [API documentation](https://normapi.com/en/docs): Endpoints, authentication, request and response shapes for validating, generating and parsing invoices — parsing reads an incoming XRechnung, ZUGFeRD or Factur-X back into the generation request, with the totals and VAT breakdown as stated and a list of whatever the shape does not carry — invoices, credit notes, corrected, partial and final invoices, with allowances and charges, credit transfer, SEPA direct debit or card — findings carry the same plain-language explanations, in English or German. Also: embedding the XML in your own PDF (checked against PDF/A-3 with veraPDF), safe retries with an Idempotency-Key, per-customer counts, keys and monthly ceilings for software that invoices on behalf of its own customers (multi-tenancy, the X-Normapi-Customer header and /v1/customers), and a table of exactly what is checked for each format. With curl and TypeScript examples. - [MCP server](https://normapi.com/en/docs/mcp): The API as tools for AI agents: hosted at https://normapi.com/mcp (Streamable HTTP, OAuth or API key) and as `npx @normapi/mcp` (stdio). validate_invoice, parse_invoice and explain_rule need no account; generate_invoice uses the user's allowance. Setup for Claude, ChatGPT, Claude Code, Cursor and VS Code. - [Pricing](https://normapi.com/en/pricing): Flat monthly plans with an allowance of generated invoices: 50 a month free, 500 on Starter (€19), 2,500 on Business (€49), 10,000 on Scale (€149, then €0.02 per further invoice up to a monthly cap the customer sets, at most 32,500 invoices a month in all; Starter and Business answer 402 past the allowance); paid yearly each costs ten months (€190, €490, €1,490). With an individual contract and an SLA, or beyond Scale's ceiling: Volume, €599 a month for 900,000 generated invoices a year on a 12-month term, or €5,990 for the contract year paid in advance, €0.01 per invoice beyond that. The page tabulates the yearly cost from 6,000 to 1,000,000 invoices a year. Every plan generates invoices, credit notes, corrected, partial and final invoices with allowances, charges, direct debit or card payment; sending, archiving and Peppol are not included. Validation and parsing are free and unmetered on every plan. - [Enterprise](https://normapi.com/en/enterprise): What a company asks before it builds invoicing on NormAPI: the volume contract and SLA beside the availability measured so far, what happens in an outage, how fast new KoSIT rule sets go live, API stability, the exact output formats, multi-tenancy for software that invoices for its own customers, data protection, who runs the service, and how to leave — the OpenAPI file, the same open-source KoSIT validator and configuration to run yourself, and the CC0 sample cases as an acceptance test for a successor. - [Status](https://normapi.com/en/status): Whether the API and normapi.de answer right now, uptime over 30 and 90 days, each day of the last 90 and every outage with its duration — measured from outside by UptimeRobot every five minutes since 14 August 2026, at most five minutes old. - [Home](https://normapi.com/en): What the API does and where it stops: generation from JSON, validation against the KoSIT rule set, incoming invoices read into JSON, and no transmission, archiving or Peppol access point. An at-a-glance block with the formats, the validator release, every price, the measured availability and where it runs. ## Guides - [E-invoicing in Germany](https://normapi.com/en/e-invoicing-germany): The German mandate for developers: what changes in 2027 and 2028, which formats count as compliant, and what a receiving system has to be able to do. - [XRechnung or ZUGFeRD](https://normapi.com/en/xrechnung-or-zugferd): The two formats as two separate choices — rule set (XRechnung or EN 16931 alone) and container (plain XML or PDF with XML) — what federal authorities, states and businesses accept, and the same invoice to download in every combination. - [The ZUGFeRD format](https://normapi.com/en/zugferd-format): What a ZUGFeRD file is made of, read from a real one: PDF/A-3, the factur-x.xml attachment, AFRelationship, the XMP fields, the BT-24 identifier of each of the six profiles, and every version from 1.0 to 2.5.2 / Factur-X 1.09.2. - [ZUGFeRD Extended or XRechnung](https://normapi.com/en/zugferd-extended-or-xrechnung): Why ZUGFeRD EXTENDED carries #conformant# rather than #compliant#, why authorities refuse it although standard validators stay silent, and which profile to send instead. - [EN 16931](https://normapi.com/en/en-16931): The European standard behind XRechnung and ZUGFeRD: its parts, the 2026 edition and why invoices still declare 2017, free and paid access, CIUS and extensions, ViDA from 2030, and the 223 EN 16931 rules in KoSIT's rule set v2026-08-31, counted by family. - [Leitweg-ID](https://normapi.com/en/leitweg-id): Where to find a German public authority’s Leitweg-ID, who assigns it, what goes in BT-10 on invoices to businesses, the format with its MOD 97-10 check digits, and an in-browser checker. - [Invoicing German federal authorities](https://normapi.com/en/xrechnung-to-federal-authorities): OZG-RE, the only federal invoice platform since September 2025 (the ZRE is switched off): who uses it, the 991/992/993 prefixes, registration, the four channels, size limits and common rejections. A guide, not the portal. - [The KoSIT validator as an API](https://normapi.com/en/kosit-validator-api): For teams that generate invoices with horstoeko/zugferd, Mustang or another free library: the official KoSIT check as one HTTP call instead of a self-hosted Java validator, with PHP, Java and CI examples. Free. - [E-invoice API](https://normapi.com/en/e-invoice-api): The API at a glance: XRechnung 3.0.2 (UBL, CII) and ZUGFeRD 2 / Factur-X generated from JSON, each checked with KoSIT validator 1.6.3 before it leaves; validation and parsing of incoming invoices into JSON free and unlimited; for software vendors, usage, keys and monthly ceilings per customer of their own; processing in the EU, no storage; prices; one curl example. - [Checking and reading incoming e-invoices](https://normapi.com/en/incoming-invoice-validation): What the BMF letter of 15 October 2025 expects on receipt — format, business-rule and content errors and which a machine can catch — and how to validate an incoming XRechnung, ZUGFeRD or Factur-X and read it into JSON over the API, both free. - [Create an e-invoice](https://normapi.com/en/create-e-invoice): A free form that turns seller, buyer, lines and payment into an XRechnung (UBL or CII) or a ZUGFeRD PDF, checked with the KoSIT validator before the download. Kleinunternehmer (§ 19), reverse charge, Skonto, credit notes; no account, 10 invoices a day. - [Convert a PDF invoice into an e-invoice](https://normapi.com/en/convert-pdf-to-e-invoice): An invoice PDF from Word, Excel or other software made a ZUGFeRD e-invoice: the same page, the invoice data entered once in a form and put inside as XML, checked with the KoSIT validator and the finished file with veraPDF as PDF/A-3. 83 of 86 real-world invoice PDFs passed in our test; free account, 50 invoices a month. - [E-invoice examples](https://normapi.com/en/e-invoice-examples): 40 German sample invoices, each as XRechnung UBL, XRechnung CII and ZUGFeRD PDF, with the JSON request that generates it: VAT rates and exemptions, reverse charge, export, credit note, corrected, progress and final invoices, Skonto, direct debit, card, Leitweg-ID, Peppol addresses. Every file checked with the KoSIT validator (v2026-08-31); CC0, no attribution needed. - [ZUGFeRD viewer](https://normapi.com/en/zugferd-viewer): The XML inside a ZUGFeRD or Factur-X PDF, read in the browser and laid out, to compare with the visible PDF. Free. - [XRechnung to PDF](https://normapi.com/en/xrechnung-to-pdf): An XRechnung or ZUGFeRD invoice turned into a readable PDF in the browser, with the original file name, time and SHA-256. Free. - [XRechnung viewer](https://normapi.com/en/xrechnung-viewer): Open an XRechnung (UBL or CII) or the XML inside a ZUGFeRD/Factur-X PDF and read it laid out: parties, lines, VAT, totals, payment details. Built in the browser without uploading; save as PDF; a KoSIT check on request. Free. - [Error reference](https://normapi.com/en/errors): Index of every XRechnung validation rule, with the ones that need explaining linked to their own page. - [Rule set changelog](https://normapi.com/en/ruleset): Which KoSIT rule set NormAPI validates against (currently v2026-08-31), what each release changed, and what an existing integration has to do about it. ## Studies Measurements published with their data, under CC BY 4.0. Nothing else in this market publishes numbers, so these are the pages worth quoting rather than paraphrasing. - [Validator comparison: same defect, different answers](https://normapi.com/en/study/validator-comparison): Twenty-nine XRechnung documents, each exactly one scripted change away from the same valid invoice, through two independent validators. They agree on 22 and disagree on 7. - [Eleven free online validators, the same invoice, one day](https://normapi.com/en/study/online-validators): The same three files from the official KoSIT test suite submitted to eleven free online tools on 15 September 2026, with every verdict quoted and dated. - [Sample e-invoices put to the test: 810 XRechnung and ZUGFeRD files](https://normapi.com/en/study/sample-invoices): Every freely downloadable sample invoice from 19 publishers (KoSIT, FeRD, CEN, libraries, vendor sites) through the KoSIT validator v2026-08-31 on 19 October 2026: 549 of 810 pass, and on 22 of FeRD's 53 official ZUGFeRD 2.5.2 samples KoSIT and FeRD's own report disagree. ## Rule groups Families where the rules share one mechanism, explained once rather than once per code. - [The German rules of XRechnung — what applies on top of EN 16931](https://normapi.com/en/errors/groups/german-rules): The BR-DE and BR-TMP rules of XRechnung: Leitweg-ID, contact details, payment data, invoice type, date formats — every rule with its cause and its fix. - [VAT categories and their 98 validation rules](https://normapi.com/en/errors/groups/vat-categories): The ten XRechnung tax categories — S, Z, E, AE, K, G, O, L, M, B — and the rules written out separately for each of them. - [Code lists — which values are permitted at all](https://normapi.com/en/errors/groups/code-lists): The BR-CL rules check that a coded field carries a value from the list prescribed for it: UNTDID, ISO 4217, ISO 3166, UN/ECE Rec 20. - [BR-DEC: decimal places — two, everywhere](https://normapi.com/en/errors/groups/decimal-places): The BR-DEC rules allow at most two decimal places for every amount in an XRechnung. Twenty-one rules, one sentence. - [XRechnung Extension — when the stricter rules apply](https://normapi.com/en/errors/groups/xrechnung-extension): The BR-DEX rules apply only to the XRechnung Extension, not to the ordinary CIUS. What they add, and when they apply at all. - [The core EN 16931 rules — which fields an invoice has to carry](https://normapi.com/en/errors/groups/core-rules): The mandatory-field checks of EN 16931: invoice number, date, currency, seller, buyer, tax details — every rule with its cause and its fix. - [Calculation and cross-field rules — when the totals do not add up](https://normapi.com/en/errors/groups/calculation-rules): The BR-CO rules check relationships between fields: totals that have to reconcile, and entries that exclude one another. Every rule with its cause and its fix. - [Peppol BIS rules — what applies on top when delivery goes through Peppol](https://normapi.com/en/errors/groups/peppol): The PEPPOL-EN16931 rules apply on top as soon as an invoice travels the Peppol network: electronic addresses, business process, no empty elements. - [Clean vehicles (CVD) — what a vehicle invoice has to carry on top](https://normapi.com/en/errors/groups/clean-vehicles): The CVD rules apply to invoices for vehicles sold to the public sector: vehicle category in BT-158, drive type in BT-161, plus contract and lot reference. ## Fields - [Field reference](https://normapi.com/en/errors/fields): Index of every BT field with its own reference page. What each BT field means, whether it is mandatory or conditional, its UBL and CII XML mapping where a rule explanation states one, and which rules check it. - [BT-5](https://normapi.com/en/errors/fields/bt-5): Invoice currency code. The currency every amount in the document is read in — mandatory on every invoice. An ISO 4217 code, EUR for the German market in the normal case. Every amount additionally carries its own currencyID attribute, which has to agree with BT-5. Checked by BR-05, BR-DEX-14, PEPPOL-EN16931-R005. - [BT-6](https://normapi.com/en/errors/fields/bt-6): VAT accounting currency code. The currency VAT is reported to the tax authority in — set only when it differs from the invoice currency (BT-5). Where BT-6 is present, the tax amount in that currency (BT-111) must be present too. Checked by BR-53, PEPPOL-EN16931-R005, PEPPOL-EN16931-R054. - [BT-10](https://normapi.com/en/errors/fields/bt-10): Buyer reference. Mandatory on every XRechnung, including B2B. For invoices to a German public authority this is the Leitweg-ID, which routes the invoice to the right office; in B2B it carries whatever reference the buyer asked for, an order number for instance. Only checked for being non-empty — the rule set never looks at the Leitweg-ID’s structure or check digit. Checked by BR-DE-15. - [BT-111](https://normapi.com/en/errors/fields/bt-111): Invoice total VAT amount in accounting currency. The VAT amount converted into the VAT accounting currency (BT-6) — required as soon as BT-6 is set. A currency on its own states no amount: without BT-111 it stays open how much tax is owed in that currency. The value sits in a second cac:TaxTotal without a cac:TaxSubtotal, carrying the accounting currency as currencyID. Checked by BR-53. - [BT-114](https://normapi.com/en/errors/fields/bt-114): Rounding amount. A balancing entry that brings the amount due for payment (BT-115) to two decimal places. It appears only where rounding is actually needed — in practice usually together with a prepaid amount (BT-113), because with no prepayment BT-115 simply equals BT-112. Checked by BR-CO-16, BR-DEX-09. - [BT-115](https://normapi.com/en/errors/fields/bt-115): Amount due for payment. The amount actually due: invoice total with VAT (BT-112) minus any amount already paid (BT-113) plus the rounding amount (BT-114). Mandatory on every invoice, explicitly even where it equals BT-112 with no prepayment — the norm requires each total in its own right, none may be inferred from the others. Checked by BR-15, BR-CO-16, BR-DEX-09. - [BT-146](https://normapi.com/en/errors/fields/bt-146): Item net price. The price per unit after any price discount — mandatory on every invoice line. For a flat fee the net price is simply the line total at a quantity of 1. Checked by BR-26. - [BT-148](https://normapi.com/en/errors/fields/bt-148): Item gross price. A line’s list price before the discount — unlike the net price (BT-146), optional: with no gross price sent, no rule concerns it. Once it is set, it must be positive and reconcile as net price = gross price − discount. Checked by BR-28. ## Error codes One page per rule, each stating what the rule requires, why an invoice trips it, and what to change to make it pass. - [BR-01](https://normapi.com/en/errors/br-01): The invoice must carry a specification identifier (BT-24), which tells the recipient which rule set the invoice was built against. - [BR-02](https://normapi.com/en/errors/br-02): The invoice must carry an invoice number (BT-1) — the identifier the recipient books it under, pays against and refers back to. A reminder, a credit note and a remittance advice all point at it later. - [BR-03](https://normapi.com/en/errors/br-03): The invoice must carry an issue date (BT-2) — the date it was issued, not the date of supply and not the date it was sent. - [BR-04](https://normapi.com/en/errors/groups/core-rules#BR-04): The invoice must carry an invoice type code (BT-3) — the code saying whether this is an invoice, a credit note or a partial invoice. - [BR-05](https://normapi.com/en/errors/groups/core-rules#BR-05): The invoice must name an invoice currency (BT-5). Every amount in the document is read in that currency. - [BR-06](https://normapi.com/en/errors/groups/core-rules#BR-06): The invoice must contain the seller name (BT-27) — the full registered name the company trades under. - [BR-07](https://normapi.com/en/errors/br-07): The invoice must contain the buyer name (BT-44) — the name the recipient expects the invoice under. - [BR-08](https://normapi.com/en/errors/br-08): The invoice must contain the seller postal address (BG-5) — the group holding street, city, post code and country. - [BR-09](https://normapi.com/en/errors/groups/core-rules#BR-09): The seller postal address must contain a country code (BT-40) — the two-letter ISO 3166-1 code, not the country's name spelled out. - [BR-10](https://normapi.com/en/errors/groups/core-rules#BR-10): The invoice must contain the buyer postal address (BG-8) — the counterpart to BG-5 on the recipient's side. - [BR-11](https://normapi.com/en/errors/groups/core-rules#BR-11): The buyer postal address must contain a country code (BT-55) — the same requirement as BR-09, on the recipient's side. - [BR-12](https://normapi.com/en/errors/groups/core-rules#BR-12): The invoice must contain the sum of line net amounts (BT-106). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others. - [BR-13](https://normapi.com/en/errors/groups/core-rules#BR-13): The invoice must contain the total amount without VAT (BT-109). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others. - [BR-14](https://normapi.com/en/errors/groups/core-rules#BR-14): The invoice must contain the total amount with VAT (BT-112). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others. - [BR-15](https://normapi.com/en/errors/groups/core-rules#BR-15): The invoice must contain the amount due for payment (BT-115). The norm requires each of the totals explicitly — none of them may be left to be inferred from the others. - [BR-16](https://normapi.com/en/errors/br-16): The invoice must contain at least one invoice line (BG-25). A document consisting only of header and total data is not permitted. - [BR-17](https://normapi.com/en/errors/groups/core-rules#BR-17): Where the payee (BG-10) differs from the seller, the payee name (BT-59) must be provided. Who receives the money may not be left open. - [BR-18](https://normapi.com/en/errors/groups/core-rules#BR-18): Where the seller has a tax representative (BG-11), the representative's name (BT-62) must be provided. - [BR-19](https://normapi.com/en/errors/groups/core-rules#BR-19): Where the seller has a tax representative, that representative's postal address (BG-12) must be provided — the same requirement as BR-08, for a third party. - [BR-20](https://normapi.com/en/errors/br-20): Where the seller has a tax representative, that representative's address must carry a country code (BT-69) — the same requirement as BR-09 and BR-11, for a third party. - [BR-21](https://normapi.com/en/errors/groups/core-rules#BR-21): Every invoice line (BG-25) must carry a line identifier (BT-126). It is the anchor the recipient uses to discuss or dispute a single row. - [BR-22](https://normapi.com/en/errors/groups/core-rules#BR-22): Every invoice line must carry an invoiced quantity (BT-129) — including where the line is a flat fee. - [BR-23](https://normapi.com/en/errors/groups/core-rules#BR-23): The invoiced quantity must carry a unit of measure (BT-130) — a code from UN/ECE Recommendation 20, not your item master's own abbreviation. - [BR-24](https://normapi.com/en/errors/groups/core-rules#BR-24): Every invoice line must carry a net amount (BT-131) — the amount of the row before VAT. - [BR-25](https://normapi.com/en/errors/br-25): Every invoice line must carry an item name (BT-153). Without one the row states an amount for something unnamed. - [BR-26](https://normapi.com/en/errors/groups/core-rules#BR-26): Every invoice line must carry an item net price (BT-146) — the price per unit after any price discount. - [BR-27](https://normapi.com/en/errors/br-27): A line's net price may not be negative. A minus belongs in the quantity or in a credit note, never in the price. - [BR-28](https://normapi.com/en/errors/br-28): A line's gross price (BT-148) may not be negative — the list price before the discount, not the net price of BR-27. Unlike that one it is optional: with no gross price there is nothing for BR-28 to report. - [BR-29](https://normapi.com/en/errors/groups/core-rules#BR-29): Where both the start and the end of the invoicing period are given, the end must fall on or after the start. - [BR-30](https://normapi.com/en/errors/groups/core-rules#BR-30): Where both the start and the end of a line period are given, the end must fall on or after the start — the same check as BR-29, per line. - [BR-31](https://normapi.com/en/errors/groups/core-rules#BR-31): Every document-level allowance (BG-20) must carry an amount (BT-92). An allowance or charge without an amount changes nothing, and then does not belong in the document. - [BR-32](https://normapi.com/en/errors/groups/core-rules#BR-32): Every document-level allowance (BG-20) must carry a VAT category code (BT-95). It decides which block of the VAT breakdown the amount flows into. - [BR-33](https://normapi.com/en/errors/groups/core-rules#BR-33): Every document-level allowance (BG-20) must carry a reason — in plain text (BT-97), as a code (BT-98), or both. An amount with no justification is something the recipient cannot check. - [BR-36](https://normapi.com/en/errors/groups/core-rules#BR-36): Every document-level charge (BG-21) must carry an amount (BT-99). An allowance or charge without an amount changes nothing, and then does not belong in the document. - [BR-37](https://normapi.com/en/errors/groups/core-rules#BR-37): Every document-level charge (BG-21) must carry a VAT category code (BT-102). It decides which block of the VAT breakdown the amount flows into. - [BR-38](https://normapi.com/en/errors/groups/core-rules#BR-38): Every document-level charge (BG-21) must carry a reason — in plain text (BT-104), as a code (BT-105), or both. An amount with no justification is something the recipient cannot check. - [BR-41](https://normapi.com/en/errors/groups/core-rules#BR-41): Every invoice line allowance (BG-27) must carry an amount (BT-136). An allowance or charge without an amount changes nothing, and then does not belong in the document. - [BR-42](https://normapi.com/en/errors/br-42): Every invoice line allowance (BG-27) must carry a reason — in plain text (BT-139), as a code (BT-140), or both. An amount with no justification is something the recipient cannot check. - [BR-43](https://normapi.com/en/errors/br-43): Every invoice line charge (BG-28) must carry an amount (BT-141) — a charge with no amount changes nothing and does not belong in the document. - [BR-44](https://normapi.com/en/errors/groups/core-rules#BR-44): Every invoice line charge (BG-28) must carry a reason — in plain text (BT-144), as a code (BT-145), or both. An amount with no justification is something the recipient cannot check. - [BR-45](https://normapi.com/en/errors/groups/core-rules#BR-45): Every VAT breakdown block (BG-23) must contain the category taxable amount (BT-116). The breakdown is where the tax becomes traceable. - [BR-46](https://normapi.com/en/errors/groups/core-rules#BR-46): Every VAT breakdown block (BG-23) must contain the category tax amount (BT-117). The breakdown is where the tax becomes traceable. - [BR-47](https://normapi.com/en/errors/br-47): Every VAT breakdown block must be defined through a VAT category code (BT-118) — one of the ten BR-CL-17 permits. Those are S, Z, E, AE, K, G, O, L, M and B. - [BR-48](https://normapi.com/en/errors/groups/core-rules#BR-48): Every VAT breakdown block must carry a VAT category rate (BT-119), unless the invoice is not subject to VAT at all. - [BR-49](https://normapi.com/en/errors/groups/core-rules#BR-49): A payment instruction (BG-16) must state the payment means code (BT-81) — how the invoice is meant to be paid. - [BR-50](https://normapi.com/en/errors/groups/core-rules#BR-50): Where a credit transfer is given as the payment means, the payee account identifier (BT-84) must accompany it. An instruction to transfer needs somewhere to transfer to. - [BR-51](https://normapi.com/en/errors/br-51): A full card primary account number must never appear in an invoice — implemented as a plain length limit: at most ten characters in the field. That matches the first six and last four digits PCI DSS allows at most. - [BR-52](https://normapi.com/en/errors/groups/core-rules#BR-52): Every additional supporting document (BG-24) must carry a reference (BT-122) — the number under which the recipient can find the document. - [BR-53](https://normapi.com/en/errors/groups/core-rules#BR-53): Where a separate VAT accounting currency (BT-6) is given, the tax total in that currency (BT-111) must be provided too. A currency on its own states no amount. - [BR-54](https://normapi.com/en/errors/br-54): Every item attribute (BG-32) must consist of a name (BT-160) and a value (BT-161). An attribute missing either describes nothing. - [BR-55](https://normapi.com/en/errors/groups/core-rules#BR-55): Every preceding invoice reference (BG-3) must contain the preceding invoice's number (BT-25). Without it the group refers to nothing in particular. - [BR-56](https://normapi.com/en/errors/groups/core-rules#BR-56): Every tax representative party (BG-11) must carry its VAT identifier (BT-63). Without it the representation cannot be traced for tax purposes. - [BR-57](https://normapi.com/en/errors/br-57): Where a deliver-to address (BG-15) is sent, it must contain a country code (BT-80) — the same requirement as BR-09 and BR-11, for the delivery address. - [BR-61](https://normapi.com/en/errors/br-61): Where the payment means code means a credit transfer — SEPA, local or non-SEPA international — the payee account identifier (BT-84) must be provided. - [BR-62](https://normapi.com/en/errors/groups/core-rules#BR-62): Where the seller electronic address (BT-34) is sent, it must carry a scheme identifier. The attribute says which register the identifier comes from — without it the value is only a string. - [BR-63](https://normapi.com/en/errors/groups/core-rules#BR-63): Where the buyer electronic address (BT-49) is sent, it must carry a scheme identifier. The attribute says which register the identifier comes from — without it the value is only a string. - [BR-64](https://normapi.com/en/errors/groups/core-rules#BR-64): Where the item standard identifier (BT-157) is sent, it must carry a scheme identifier. The attribute says which register the identifier comes from — without it the value is only a string. - [BR-65](https://normapi.com/en/errors/br-65): Where the item classification identifier (BT-158) is sent, it must carry a scheme identifier. The attribute says which register the identifier comes from — without it the value is only a string. - [BR-CO-03](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-03): The invoice may state the VAT point either as a date (BT-7) or as a code (BT-8), never as both. The two fields answer the same question: when the VAT becomes chargeable. - [BR-CO-04](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-04): Every invoice line (BG-25) must carry a VAT category code (BT-151) — S for the standard rate, E for exempt, Z for zero-rated, AE for reverse charge, and so on. - [BR-CO-09](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-09): The VAT identifiers of the seller (BT-31), the tax representative (BT-63) and the buyer (BT-48) must begin with the ISO 3166-1 alpha-2 country code. Greece is permitted to use “EL” instead. - [BR-CO-10](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-10): The sum of invoice line net amounts (BT-106) must equal the sum of the individual line net amounts (BT-131) exactly. - [BR-CO-11](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-11): The sum of allowances at document level (BT-107) must equal the sum of the individual allowance amounts (BT-92) exactly. - [BR-CO-12](https://normapi.com/en/errors/br-co-12): The sum of charges at document level (BT-108) must equal the sum of the individual charge amounts (BT-99) exactly — the counterpart to BR-CO-11. - [BR-CO-13](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-13): The invoice total without VAT (BT-109) must equal the sum of all line net amounts (BT-131) minus document-level allowances (BT-107) plus document-level charges (BT-108). - [BR-CO-14](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-14): The invoice total VAT amount (BT-110) must equal the sum of the tax amounts of all VAT categories (BT-117). - [BR-CO-15](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-15): The invoice total with VAT (BT-112) must equal the total without VAT (BT-109) plus the total VAT amount (BT-110), exactly. - [BR-CO-16](https://normapi.com/en/errors/br-co-16): The amount due for payment (BT-115) must add up: invoice total with VAT (BT-112) minus any amount already paid (BT-113) plus the rounding amount (BT-114). - [BR-CO-17](https://normapi.com/en/errors/br-co-17): Per VAT category, the tax amount (BT-117) must equal the taxable amount (BT-116) times the rate (BT-119), within one whole currency unit. The rule text does not say so; the expression the validator evaluates does, comparing with "− 1 <" and "+ 1 >" rather than to the cent. - [BR-CO-18](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-18): The invoice must contain at least one VAT breakdown group (BG-23) — one block per tax category, carrying the taxable amount, the tax amount, the category and the rate. - [BR-CO-19](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-19): If an invoicing period (BG-14) is sent, at least one date must be in it: the start (BT-73), the end (BT-74), or both. An empty period states nothing. - [BR-CO-20](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-20): If a line period (BG-26) is sent on an invoice line, at least one date must be in it: the start (BT-134), the end (BT-135), or both. The line-level counterpart to BR-CO-19. - [BR-CO-21](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-21): Every document-level allowance (BG-20) must be justified — in plain text (BT-97), as a code (BT-98), or both. An amount with no reason is something the recipient cannot check. - [BR-CO-22](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-22): Every document-level charge (BG-21) must carry a reason — in plain text (BT-104), as a code (BT-105), or both. - [BR-CO-23](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-23): Every allowance on an invoice line (BG-27) must be justified — in plain text (BT-139), as a code (BT-140), or both. - [BR-CO-24](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-24): Every charge on an invoice line (BG-28) must carry a reason — in plain text (BT-144), as a code (BT-145), or both. - [BR-CO-26](https://normapi.com/en/errors/groups/calculation-rules#BR-CO-26): So the buyer can identify the supplier automatically, at least one seller identifier must be present: a seller identifier (BT-29), the legal registration identifier (BT-30), or the VAT identifier (BT-31). - [BR-DE-1](https://normapi.com/en/errors/br-de-1): Every XRechnung invoice must carry the payment instructions group BG-16 — at minimum, by what means the invoice is meant to be paid. - [BR-DE-10](https://normapi.com/en/errors/br-de-10): Once a delivery address (BG-15) is in the document it must carry the city (BT-77), and otherwise the rule never fires. The group is "DELIVER TO ADDRESS", and a delivery date on its own is not one. - [BR-DE-11](https://normapi.com/en/errors/br-de-11): Once a delivery address (BG-15) is in the document it must carry the post code (BT-78) — the city beside it is BR-DE-10. EN 16931 asks only for the country in this group (BT-80, through BR-57); the city and the post code come from the German CIUS. - [BR-DE-14](https://normapi.com/en/errors/br-de-14): The VAT category rate (BT-119) must appear in every VAT breakdown (BG-23), including the exempt and reverse-charge ones where it is 0. EN 16931 allows exactly one exception through BR-48, category O for not subject to VAT; the German CIUS removes it. - [BR-DE-15](https://normapi.com/en/errors/br-de-15): Every XRechnung needs a buyer reference in BT-10 — for invoices to a German public authority that is the Leitweg-ID. It routes the invoice to the right office. All that is checked, though, is that the field is not empty: the rule set never looks at its structure or its check digit. - [BR-DE-16](https://normapi.com/en/errors/br-de-16): With tax category codes S, Z, E, AE, K, G, L or M the seller must be identifiable for tax: a VAT ID, a tax number or BG-11. Those are the VAT identifier (BT-31), the tax registration identifier (BT-32) and the tax representative (BG-11) — any one of the three will do. - [BR-DE-17](https://normapi.com/en/errors/br-de-17): The invoice type code (BT-3) should be one of the permitted UNTDID 1001 codes: 326, 380, 384, 389, 381, 875, 876 or 877. BR-DE-17 reports as a warning rather than an error, so an invoice carrying another code is not rejected for it. - [BR-DE-18](https://normapi.com/en/errors/br-de-18): Cash-discount (Skonto) information in the payment terms (BT-20) must follow a fixed machine-readable format: #SKONTO#TAGE=n#PROZENT=n.nn#, one entry per line, all in capitals, the percentage with a dot and exactly two decimals. - [BR-DE-19](https://normapi.com/en/errors/br-de-19): If SEPA credit transfer is declared as the payment means (BT-81 with code 58), the payment account identifier (BT-84) should be a correct IBAN. It is checked only for code 58 and only as a warning: code 30, the generic credit transfer, goes through unchecked. - [BR-DE-2](https://normapi.com/en/errors/br-de-2): Every XRechnung invoice must carry the "SELLER CONTACT" group (BG-6) — a named contact at the seller, with a way to reach them. EN 16931 leaves this group optional; it becomes mandatory only through the German CIUS, including B2B. - [BR-DE-20](https://normapi.com/en/errors/br-de-20): For SEPA direct debit (BT-81 with code 59), the debited account identifier (BT-91) should be a correct IBAN — the check digit, and only as a warning. The account is the buyer's, not yours: the number comes from the mandate the customer gave you. - [BR-DE-21](https://normapi.com/en/errors/br-de-21): The specification identifier (BT-24) should be XRechnung's — exactly three values are accepted, and the rule only warns. It tells the recipient that the invoice was built to XRechnung, and in which variant. - [BR-DE-22](https://normapi.com/en/errors/br-de-22): All attachments embedded in an invoice must carry distinct filenames — the name in the filename attribute is all that tells them apart. The recipient files them under exactly that name. - [BR-DE-23-a](https://normapi.com/en/errors/br-de-23-a): For a credit transfer (BT-81 with code 30 or 58) the document must carry group BG-17 with the payee's bank account. Asking for a transfer means saying where to — and the IBAN inside it is required by BR-50 and BR-61 from the norm, not by this rule. - [BR-DE-23-b](https://normapi.com/en/errors/br-de-23-b): For a credit transfer (BT-81 with code 30 or 58) no card data (BG-18) and no direct-debit data (BG-19) may sit beside it. BR-DE-23-a is its counterpart and requires the matching group, BG-17. - [BR-DE-24-a](https://normapi.com/en/errors/br-de-24-a): For a card payment (BT-81 with code 48, 54 or 55) the document must carry group BG-18 with the card details. What goes inside it is BR-51's business: the last digits of the card number, never the full PAN. - [BR-DE-24-b](https://normapi.com/en/errors/br-de-24-b): For a card payment (BT-81 with code 48, 54 or 55) neither credit-transfer data (BG-17) nor direct-debit data (BG-19) may sit beside it. BR-DE-24-a is its counterpart and requires the matching group, BG-18. - [BR-DE-25-a](https://normapi.com/en/errors/br-de-25-a): If the payment means is SEPA direct debit (BT-81 with code 59), group BG-19 ("DIRECT DEBIT") must be transmitted — with the data the collection rests on: mandate reference, creditor identifier and the account to be debited. - [BR-DE-25-b](https://normapi.com/en/errors/br-de-25-b): If the payment means is SEPA direct debit (BT-81 with code 59), no credit-transfer data (BG-17) and no card data (BG-18) may be transmitted. - [BR-DE-26](https://normapi.com/en/errors/br-de-26): A corrected invoice (BT-3 with code 384) should name the invoice it corrects, in group BG-3 "PRECEDING INVOICE REFERENCE". It is reported as a warning rather than an error — though without it the recipient cannot tell what is being corrected. - [BR-DE-27](https://normapi.com/en/errors/br-de-27): The seller contact telephone number (BT-42) should contain at least three digits — a plausibility check rather than a format rule, and reported as a warning. - [BR-DE-28](https://normapi.com/en/errors/br-de-28): The seller contact email address (BT-43) should be plausibly formed: exactly one @, no whitespace, and a dot in the domain. The rule text asks for more than the expression tests, and it reports only a warning either way. - [BR-DE-3](https://normapi.com/en/errors/br-de-3): The seller's postal address (BG-5) must carry the city: BT-37, mandatory in XRechnung and not required by EN 16931 at all. It is the seller's address that is meant — the buyer's city is BR-DE-8, a differing delivery address BR-DE-10. - [BR-DE-30](https://normapi.com/en/errors/br-de-30): If the invoice carries direct-debit data (BG-19), it must include the bank-assigned creditor identifier (BT-90) — the SEPA identifier under which you are allowed to collect. - [BR-DE-31](https://normapi.com/en/errors/br-de-31): If the invoice carries direct-debit data (BG-19), it must include the debited account identifier (BT-91) — the buyer's IBAN the payment is collected from. - [BR-DE-4](https://normapi.com/en/errors/br-de-4): The seller's postal address must carry the post code (BT-38) — and the check is only that something is there, not that it looks like one. EN 16931 does not require BT-38 at all; the German CIUS is what makes it mandatory, with BR-DE-9 as the buyer's equivalent. - [BR-DE-5](https://normapi.com/en/errors/br-de-5): The seller contact point (BT-41) has to be filled — a named person or a department at the seller that the buyer can write to. EN 16931 carries BT-41 as an optional field and never tests it; the German CIUS is what makes it mandatory. - [BR-DE-6](https://normapi.com/en/errors/br-de-6): The seller contact needs a telephone number (BT-42), and it is an error that rejects the invoice rather than a warning. Whether what you put there is a number at all is BR-DE-27, which is only a warning. - [BR-DE-7](https://normapi.com/en/errors/br-de-7): The seller contact needs an email address (BT-43), and that is an error which rejects the invoice rather than a warning. Whether the address looks like one at all is BR-DE-28, and only as a warning. - [BR-DE-8](https://normapi.com/en/errors/br-de-8): The buyer's postal address must carry the city (BT-52) — EN 16931 asks only for the country, and the city comes from the German CIUS. It is the buyer's invoicing address that is meant, not the seller's (BR-DE-3) and not a differing delivery address (BR-DE-10). - [BR-DE-9](https://normapi.com/en/errors/br-de-9): The buyer's postal address must carry a post code (BT-53) — BR-DE-8 asks for the city beside it, BR-DE-4 the same on the seller. There is no exception for countries that have no post codes: the expression never looks at the country code. - [BR-DE-CVD-01](https://normapi.com/en/errors/br-de-cvd-01): A CVD invoice must carry the contract reference (BT-12), which is optional in an ordinary XRechnung. All that is checked is that the field has content: whitespace alone fails, anything else passes — the rule set never looks at the number itself. The expression does not show that the rule only concerns CVD invoices; that condition lives in the rule’s context, which only takes in documents whose BT-24 carries the CVD identifier. - [BR-DE-CVD-02](https://normapi.com/en/errors/br-de-cvd-02): A CVD invoice must carry the tender or lot reference (BT-17) — the identifier of the procurement procedure or lot the invoice belongs to. Only the presence of content is checked. In UBL only cac:OriginatorDocumentReference/cbc:ID counts; in CII, BT-17 has no element of its own but is a ram:AdditionalReferencedDocument, and the expression wants ram:TypeCode 50 and a ram:IssuerAssignedID in the same element. - [BR-DE-CVD-03](https://normapi.com/en/errors/br-de-cvd-03): A CVD invoice must contain at least one invoice line (BG-25) whose item carries both: an item classification identifier (BT-158) under the CVD scheme and an item attribute (BG-32) whose name (BT-160) is cva. Both have to sit on the same item — a category on one line and a drive type on another is not enough. Whether the values themselves are permitted is left to BR-DE-CVD-04 and BR-DE-CVD-05. - [BR-DE-CVD-04](https://normapi.com/en/errors/br-de-cvd-04): Where an item classification identifier (BT-158) uses the CVD scheme, its value must be one of the six vehicle categories: M1, M2, M3, N1, N2 or N3. The expression strips leading and trailing spaces first, but case matters, and any addition makes the value invalid. Classifications under other schemes are not checked by this rule. - [BR-DE-CVD-05](https://normapi.com/en/errors/br-de-cvd-05): The item attribute (BG-32) named cva carries the drive type, and its value (BT-161) must be exactly one of three codes: clean, zero-emission or other. The expression ignores leading and trailing spaces but not case. The restriction to attributes named cva lives in the rule’s context, not in the expression — an attribute named "CVA" is passed over, and on a line with a vehicle category BR-DE-CVD-06-a then reports the missing cva. - [BR-DE-CVD-06-a](https://normapi.com/en/errors/br-de-cvd-06-a): Where an item carries a vehicle category — an item classification identifier (BT-158) under the CVD scheme — the same item must have exactly one attribute whose name (BT-160) is cva: not none, and not two. Only the exact name counts; "Antriebsart" or "CVA" does not. The reverse direction is BR-DE-CVD-06-b. - [BR-DE-CVD-06-b](https://normapi.com/en/errors/br-de-cvd-06-b): Where an item carries an attribute whose name (BT-160) is cva, the same item must have exactly one item classification identifier (BT-158) under the CVD scheme: not none, and not two. Only listID="CVD" spelled exactly that way counts; the same category under another scheme does not. The reverse direction is BR-DE-CVD-06-a. - [BR-DE-TMP-32](https://normapi.com/en/errors/br-de-tmp-32): A notice, not an error: the invoice should state the delivery or service date in structured form — as the actual delivery date (BT-72), as the invoicing period (BG-14), or as a period on every single invoice line (BG-26). If all three are missing the invoice remains valid, and the validator still recommends accepting it. Only the presence of one of the elements is checked; in UBL, a cac:InvoicePeriod holding nothing but the VAT point date code (BT-8) is therefore enough, although it contains no date. - [BR-DEX-01](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-01): On an invoice carrying the Extension identifier, every embedded attachment (BT-125) must have one of seven MIME types: the six from BR-CL-24 — application/pdf, image/png, image/jpeg, text/csv and the .xlsx and .ods spreadsheet formats — plus application/xml. The comparison is character for character; “application/PDF” fails. Unlike BR-CL-24, the rule also checks an attachment with no mimeCode at all — in CII, where the schema does not require the attribute, such an attachment is caught only here. - [BR-DEX-02](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-02): Where an invoice line has sub invoice lines (BG-DEX-01), its net amount (BT-131) should equal exactly the sum of the net amounts of the sub lines directly beneath it — at every level, including sub lines that have sub lines of their own. The comparison is exact, with no rounding tolerance. The rule only warns, and it reports once for the whole invoice: the location it gives is the document, not the line that fails to add up. - [BR-DEX-03](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-03): Every sub invoice line (BG-DEX-01) must carry exactly one VAT information group, BG-DEX-06, in its item — one cac:ClassifiedTaxCategory, not none and not two. That holds at every level, sub lines of sub lines included. Only the element is counted: BR-DEX-03 does not look at the category, rate or tax scheme inside it. As with BR-DEX-02, the location given is the invoice as a whole, not the sub line concerned. - [BR-DEX-04](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-04): Where a party identifier — the seller’s (BT-29), the buyer’s (BT-46) or the payee’s (BT-60) — carries a scheme attribute, on an Extension invoice its value must come from the ISO 6523 ICD list: the same one as for BR-CL-10, plus three codes only XRechnung knows: XR01, XR02 and XR03. To let those three through, the KoSIT configuration lowers BR-CL-10 to a notice for the Extension; acceptance is decided there by BR-DEX-04. Identifiers without a schemeID are not checked, and UBL also accepts SEPA — but only for the seller and the payee, where the creditor identifier (BT-90) sits in the same element. - [BR-DEX-05](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-05): Where a legal registration identifier — the seller’s (BT-30), the buyer’s (BT-47) or the payee’s (BT-61) — carries a scheme attribute, on an Extension invoice its value must come from the ISO 6523 ICD list: the same one as for BR-CL-11, plus three codes only XRechnung knows: XR01, XR02 and XR03; BR-CL-11 itself is lowered to a notice for the Extension by the KoSIT configuration. Without a schemeID nothing is checked. In CII the rule reaches further than its field suggests, as BR-CL-11 does: it checks every ram:ID carrying a schemeID, except tax registrations (ram:SpecifiedTaxRegistration). - [BR-DEX-06](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-06): Where the item standard identifier (BT-157) carries a scheme attribute, on an Extension invoice its value must come from the ISO 6523 ICD list — the same one as for BR-CL-21, plus three codes only XRechnung knows: XR01, XR02 and XR03. Without a schemeID the rule checks nothing. Here the Extension is stricter than the CIUS: there a wrong scheme does not prevent acceptance, because the KoSIT configuration has lowered BR-CL-21 to a warning — in the Extension BR-CL-21 is only a notice, but BR-DEX-06 is an error that gets the invoice rejected. - [BR-DEX-07](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-07): The scheme attribute of the electronic address — the seller’s (BT-34) or the buyer’s (BT-49) — must carry a code from the CEF EAS list on an Extension invoice: the same list as for BR-CL-25, plus three codes only XRechnung knows: XR01, XR02 and XR03; BR-CL-25 itself is lowered to a notice for the Extension by the KoSIT configuration. Only an address that carries a schemeID is checked; that it carries one is required by BR-62 and BR-63. The comparison is exact: EM passes, “em” and “EMAIL” do not. - [BR-DEX-08](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-08): Where the delivery location identifier (BT-71) carries a scheme attribute, on an Extension invoice its value must come from the ISO 6523 ICD list — the same one as for BR-CL-26, plus three codes only XRechnung knows: XR01, XR02 and XR03; BR-CL-26 itself is lowered to a notice for the Extension by the KoSIT configuration. Without a schemeID the rule checks nothing. In CII it looks only at ram:GlobalID of the delivery location at header level, that is under ram:ApplicableHeaderTradeDelivery/ram:ShipToTradeParty. - [BR-DEX-09](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-09): On an Extension invoice the amount due for payment (BT-115) has to add up like this: total with VAT (BT-112) minus the amount already paid (BT-113) plus the rounding amount (BT-114) plus the amounts of all third-party payments (BG-DEX-09, each BT-DEX-002). Third-party payments raise the amount due — they are added, not deducted. Every cac:PrepaidPayment in the invoice goes into the sum. - [BR-DEX-10](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-10): Every third-party payment (group BG-DEX-09, cac:PrepaidPayment in UBL) has to state its type: BT-DEX-001, mapped onto cac:PrepaidPayment/cbc:ID. All that is checked is that the element is present and holds more than whitespace; which type it names, the expression does not examine. The rule applies only where BT-24 declares the Extension. - [BR-DEX-11](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-11): Every third-party payment (BG-DEX-09) has to state its amount: BT-DEX-002 in cac:PrepaidPayment/cbc:PaidAmount. The check is that the element is present and not empty — in practice, that it is present, because an empty cbc:PaidAmount already fails the schema, which wants a decimal number there. - [BR-DEX-12](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-12): Every third-party payment (BG-DEX-09) needs a description: BT-DEX-003, mapped onto cac:PrepaidPayment/cbc:InstructionID. All that is checked is that the element is present and holds more than whitespace; whether two groups carry the same description, the expression does not examine. - [BR-DEX-13](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-13): The amount of a third-party payment (BT-DEX-002, cac:PrepaidPayment/cbc:PaidAmount) may carry at most two decimals. The count works as in the BR-DEC rules: characters after the point, not the value — 100.000 fails although it is exactly one hundred. - [BR-DEX-14](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-14): The amount of a third-party payment (BT-DEX-002) must be stated in the invoice currency: the currencyID attribute on cac:PrepaidPayment/cbc:PaidAmount has to equal the invoice currency code (BT-5, cbc:DocumentCurrencyCode). The comparison is character by character — "eur" is not "EUR". - [BR-DEX-15](https://normapi.com/en/errors/groups/xrechnung-extension#BR-DEX-15): A CII invoice whose BT-24 declares the Extension should contain no ram:ParentLineID — the element through which one line points to a parent line. The Extension has sub invoice lines in UBL only — BR-DEX-02 and BR-DEX-03 exist there alone. BR-DEX-15 is a warning, so the invoice is not rejected for it. - [BR-TMP-2](https://normapi.com/en/errors/br-tmp-2): Where the invoice points at an externally stored document (BT-124), the value must be an absolute address including its scheme. A file name, a drive path, or an address with no scheme in front of it all fail. - [BR-TMP-3](https://normapi.com/en/errors/br-tmp-3): Where the item price base quantity (BT-149) appears on both the gross and the net price of a line, the two values must be identical — and where the net price carries a unit of measure (BT-150), the gross price must carry the same one. - [BR-TMP-4](https://normapi.com/en/errors/br-tmp-4): Within one supporting document (BG-24) the document description (BT-123) may appear at most once — a warning, not an error. Several names for the same attachment are not allowed — a second document needs a second BG-24 group. - [BR-TMP-5](https://normapi.com/en/errors/br-tmp-5): Within one supporting document (BG-24) there may be at most one embedded attachment (BT-125) — a warning, not an error. Two files in the same group are not allowed, even though the schema technically permits them. - [BR-TMP-6](https://normapi.com/en/errors/br-tmp-6): Dates in a UBL XRechnung must be written as YYYY-MM-DD, for example 2026-08-26, and the check reports a warning rather than an error. It does not cover every date field, though, but seven named ones: IssueDate, DueDate, StartDate, EndDate, ActualDeliveryDate, TaxPointDate and PaymentDueDate — wherever they sit, including inside referenced documents. - [BR-TMP-7](https://normapi.com/en/errors/br-tmp-7): Dates in CII are written differently from UBL: as YYYYMMDD with no separators, for example 20260826, and the surrounding element must carry the attribute format="102", which announces exactly that pattern. - [BR-TMP-CVD-01](https://normapi.com/en/errors/br-tmp-cvd-01): In a CVD invoice every item classification identifier (BT-158) on the invoice lines must carry a scheme from the UNTDID 7143 code list — or CVD, which the list does not contain. A missing or empty listID gets through the expression, though: the variable puts CVD with its surrounding spaces in front of the list, and the double space at the join matches an empty value. A missing attribute is rejected by BR-65, an empty listID="" only in CII — in UBL, BR-65 merely checks that the attribute exists. - [PEPPOL-EN16931-R001](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R001): The invoice must name the business process (BT-23) — the identifier of the process it is being sent in. It tells the recipient which rule set to expect the invoice under. - [PEPPOL-EN16931-R005](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R005): If a separate VAT accounting currency (BT-6) is given, it must differ from the invoice currency (BT-5). The field exists only for the case where tax has to be reported in another currency. - [PEPPOL-EN16931-R008](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R008): The document must contain no empty elements. A tag with no content is not an absent value; it is a claim that something was transmitted. - [PEPPOL-EN16931-R010](https://normapi.com/en/errors/peppol-en16931-r010): The buyer electronic address (BT-49) must be provided — the identifier the invoice is technically delivered to, such as an email address. The scheme that goes with it is BR-63's requirement, not this rule's. - [PEPPOL-EN16931-R020](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R020): The seller electronic address (BT-34) must be provided — the counterpart to BT-49, the address a recipient can reply or send a response message to. - [PEPPOL-EN16931-R040](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R040): Where both the base amount and the percentage of an allowance or charge are given, the amount must follow from them exactly: base amount × percentage ÷ 100. - [PEPPOL-EN16931-R041](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R041): If the percentage of an allowance or charge is given, the base amount must accompany it. A percentage with nothing to apply it to cannot be recalculated. - [PEPPOL-EN16931-R042](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R042): If the base amount of an allowance or charge is given, the percentage must accompany it — the counterpart to R041. - [PEPPOL-EN16931-R043](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R043): The indicator saying whether this is a charge or an allowance must be exactly true or false — lower case, with no alternatives. - [PEPPOL-EN16931-R043-1](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R043-1): In CII the charge indicator of an allowance or charge at document or line level must be exactly true or false. This rule checks the ram:SpecifiedTradeAllowanceCharge group. - [PEPPOL-EN16931-R043-2](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R043-2): The same requirement as R043-1, but for the allowance or charge inside the price: ram:AppliedTradeAllowanceCharge under the gross price must carry an indicator of exactly true or false. - [PEPPOL-EN16931-R044](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R044): No charge is permitted inside a line's price. The indicator there may only be false: the price knows nothing but the allowance from the gross price down to the net price. - [PEPPOL-EN16931-R046](https://normapi.com/en/errors/peppol-en16931-r046): Where a gross price is given, the net price must follow from it exactly: gross price minus the price allowance, with no tolerance. The three numbers describe one calculation and have to add up. - [PEPPOL-EN16931-R053](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R053): The invoice may contain exactly one tax total in the invoice currency — that is, exactly one block carrying a breakdown. Several tax categories belong inside that one block as several sub-blocks. - [PEPPOL-EN16931-R054](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R054): A second tax block without a breakdown is permitted only where a separate VAT accounting currency (BT-6) is given — and then exactly one. It states the tax total in the reporting currency. - [PEPPOL-EN16931-R055](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R055): The tax total in the invoice currency and the tax total in the accounting currency must carry the same operational sign. Both describe the same amount, only in two currencies. - [PEPPOL-EN16931-R061](https://normapi.com/en/errors/peppol-en16931-r061): For direct debit the mandate reference must be provided — the identifier of the mandate under which the payer agreed to the collection. - [PEPPOL-EN16931-R101](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R101): On an invoice line the only additional document reference permitted is the object identifier — type code 130. Other document references belong at document level. - [PEPPOL-EN16931-R110](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R110): If a line has a period of its own, it must fall inside the invoicing period: the line's start date may not precede the invoice's start date. - [PEPPOL-EN16931-R111](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R111): A line period's end date may not fall after the end of the invoicing period — the counterpart to R110 at the other end. - [PEPPOL-EN16931-R120](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R120): A line's net amount must follow from the line's own figures: quantity × (net price ÷ price base quantity), plus the line's charges and minus its allowances. - [PEPPOL-EN16931-R121](https://normapi.com/en/errors/peppol-en16931-r121): The price base quantity (BT-149) must be greater than zero — it states how many units the price refers to, 100 for a price per hundred. Zero fails it and so does a negative value; leaving the element out altogether is allowed and means a price per single unit. - [PEPPOL-EN16931-R130](https://normapi.com/en/errors/groups/peppol#PEPPOL-EN16931-R130): The unit of the price base quantity must be the same as the unit of the invoiced quantity. Price and quantity have to measure the same thing, or the line amount cannot be recalculated. ## Deutsch The German equivalents of the pages above. Rule pages follow `/fehler/`; group pages follow `/fehler/gruppen/`. - [Validator](https://normapi.de/validator): XRechnung oder ZUGFeRD prüfen, mit dem offiziellen KoSIT-Validator. - [API-Dokumentation](https://normapi.de/docs): Endpunkte, Authentifizierung, Anfrage- und Antwortformate. - [MCP-Server](https://normapi.de/docs/mcp): Die API als Werkzeuge für KI-Agenten: https://normapi.com/mcp und `npx @normapi/mcp`. Prüfen ohne Konto, Erzeugen mit dem Kontingent des Nutzers. - [Preise](https://normapi.de/preise): Tarife ab 19 € im Monat; 900.000 erzeugte Rechnungen im Jahr für 599 € im Monat. Die Prüfung ist in jedem Tarif kostenlos. - [Für Unternehmen](https://normapi.de/unternehmen): Vertrag, SLA, Ausfallverhalten, Regelwerk-Updates, Datenschutz, Betreiber und Ausstieg — was ein Unternehmen vor der Anbindung wissen will. - [E-Rechnungspflicht](https://normapi.de/e-rechnung-pflicht): Die deutsche E-Rechnungspflicht für Entwickler: 2027, 2028 und was ein empfangendes System können muss. - [XRechnung oder ZUGFeRD](https://normapi.de/xrechnung-oder-zugferd): Regelwerk und Verpackung als zwei getrennte Fragen, was Bund, Länder und Unternehmen annehmen, und dieselbe Rechnung in jedem Format zum Herunterladen. - [Das ZUGFeRD-Format](https://normapi.de/zugferd-format): Aufbau einer ZUGFeRD-Datei an einer echten Datei: PDF/A-3, factur-x.xml, XMP, Profilkennungen und alle Versionen bis 2.5.2. - [ZUGFeRD Extended oder XRechnung](https://normapi.de/zugferd-extended-oder-xrechnung): Warum EXTENDED #conformant# trägt, Behörden es zurückweisen und welches Profil stattdessen. - [Die Norm EN 16931](https://normapi.de/en-16931): Teile, Ausgabe 2026, Bezug, CIUS und Erweiterung, ViDA und die Regeln der Norm im KoSIT-Regelwerk, nach Familie gezählt. - [Leitweg-ID](https://normapi.de/leitweg-id): Wo Sie die Leitweg-ID finden, wer sie vergibt, was bei Unternehmen in BT-10 gehört, Aufbau und Prüfziffer, mit Prüfer im Browser. - [XRechnung an den Bund](https://normapi.de/xrechnung-an-den-bund): Anleitung zur OZG-RE, der einzigen Rechnungsplattform des Bundes: Registrierung, Wege, Grenzen, Ablehnungsgründe. Nicht das Portal selbst. - [KoSIT-Validator als API](https://normapi.de/kosit-validator-api): Die offizielle KoSIT-Prüfung als ein HTTP-Aufruf für Rechnungen aus horstoeko, Mustang & Co. — ohne Java und Docker. - [E-Rechnung API](https://normapi.de/e-rechnung-api): Die API im Überblick: XRechnung (UBL, CII) und ZUGFeRD aus JSON, jede Rechnung mit KoSIT geprüft, Prüfen und Auslesen eingehender Rechnungen kostenlos; für Software-Anbieter Nutzung, Schlüssel und Obergrenzen je eigenem Kunden; Preise und ein Beispielaufruf. - [E-Rechnung erstellen](https://normapi.de/e-rechnung-erstellen): Kostenloses Formular: XRechnung (UBL, CII) oder ZUGFeRD-PDF, vor dem Download mit dem KoSIT-Validator geprüft. Kleinunternehmer, Reverse Charge, Skonto, Gutschriften; ohne Anmeldung, 10 Rechnungen am Tag. - [PDF in E-Rechnung umwandeln](https://normapi.de/pdf-in-e-rechnung-umwandeln): Die PDF-Rechnung aus Word, Excel oder dem eigenen Programm als ZUGFeRD-E-Rechnung: dieselbe Seite, die Rechnungsdaten einmal ins Formular, als XML hinein, mit KoSIT geprüft und die fertige Datei mit veraPDF als PDF/A-3. Kostenloses Konto, 50 Rechnungen im Monat. - [ZUGFeRD Viewer](https://normapi.de/zugferd-viewer): Die XML aus einem ZUGFeRD- oder Factur-X-PDF lesbar anzeigen, ohne Upload. - [XRechnung in PDF umwandeln](https://normapi.de/xrechnung-in-pdf-umwandeln): XRechnung oder ZUGFeRD im Browser in ein lesbares PDF umwandeln, mit Dateiname, Zeitpunkt und SHA-256. - [XRechnung Viewer](https://normapi.de/xrechnung-viewer): XRechnung oder ZUGFeRD-PDF online öffnen und lesbar anzeigen, ohne Upload; als PDF speichern, auf Wunsch mit KoSIT prüfen. - [Fehlerreferenz](https://normapi.de/fehler): Index aller XRechnung-Prüfregeln. - [Startseite](https://normapi.de): Was die API tut und wo sie aufhört: aus JSON erzeugen, gegen das KoSIT-Regelwerk prüfen, eingehende Rechnungen als JSON auslesen — kein Versand, keine Archivierung, kein Peppol-Zugangspunkt.