NormAPI llms.txt changelog

https://normapi.com/llms.txt

− > 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.− 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.− (`/fehler/br-de-15`); English lives under `/en` (`/en/errors/br-de-15`).− - [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 sa− - [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.− - [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 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.− 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.+ > hybrid ZUGFeRD PDFs, on our page, on the account’s own letterhead or embedded in the+ > caller’s own PDF. Parsing reads an incoming XRechnung, ZUGFeRD or Factur-X back into+ > the JSON generation takes.+ Germany requires structured e-invoices in domestic business-to-business trade: from+ January 2027 from businesses over €800,000 prior-year turnover, from January 2028 from+ all of them. Small businesses under § 19 UStG and invoices up to €250 are exempt from+ issuing. Receiving them has been mandatory for every business since January 2025.+ (`/preise`); English lives under `/en` (`/en/pricing`).+ - [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 sa+ - [NormAPI in Claude](https://normapi.com/en/claude): For people rather than developers: add https://normapi.com/mcp as a custom connector in claude.ai or Claude Desktop, then ask Claude to check, read or explain an e-invoice (no account) or to create one (NormAPI account), a ZUGFeRD PDF on the account’s own letterhead when one is uploaded. The three steps with screenshots, and what happens to the data.+ - [NormAPI in ChatGPT](https://normapi.com/en/chatgpt): The plugin "NormAPI – XRechnung & ZUGFeRD" in ChatGPT's directory (published 28 October 2026): install it, then ask ChatGPT to check, read or explain an e-invoice (no account) or to create an XRechnung (NormAPI account). The three steps with screenshots, and what happens to the data.+ - [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.+ - [E-invoicing in Austria](https://normapi.com/en/e-invoicing-austria): Seen from Austria: the federal e-invoice duty through e-rechnung.gv.at (ebInterface, Peppol), no B2B duty, and what applies to invoices to German customers and authorities and from German suppliers (ZUGFeRD, XRechnung). NormAPI does not check ebInterface.+ - [E-invoicing in Switzerland](https://normapi.com/en/e-invoicing-switzerland): Seen from Switzerland: the federal administration’s e-invoice requirement, the QR-bill (not an EN 16931 e-invoice), no B2B duty, and what applies to invoices to German customers and authorities and from German suppliers (ZUGFeRD, XRechnung).+ - [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. With a free account, the ZUGFeRD PDF on the user’s own letterhead, uploaded once.+ - [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.+ - [Error reference](https://normapi.com/en/errors): Index of every XRechnung validation rule, one row per code with what it checks; for BR-DE and BR-CO also the official message and the fix.+ What each rule requires, linked to its row in the error reference. Why an invoice+ trips it and what to change come with every finding the validator, the API and the+ MCP server return.+ - [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#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#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#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#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#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#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#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#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#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#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.

Showing the first 40 of each.

https://normapi.com/llms.txt

− > An HTTP API that validates and generates German e-invoices. Validation runs the− > official KoSIT validator against the XRechnung rule set, so a result here is the− > hybrid ZUGFeRD PDFs, on our page or embedded in the caller’s own PDF.− Rule set in use: v2026-08-31. Validation is free and unmetered, including− through the API; only generation is billed.− - [API documentation](https://normapi.com/en/docs): Endpoints, authentication, request and response shapes for validating and generating invoices — 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, and a table of exactly− - [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 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.05 per further invoice up to a monthly cap the customer sets, at most 30,000 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 f− - [Enterprise](https://normapi.com/en/enterprise): What a company asks before it builds invoicing on NormAPI: the volume contract and SLA, what happens in an outage, how fast new KoSIT rule sets go live, API stability, the exact output formats, data protection, who runs the service, and how to leave.− - [Home](https://normapi.com/en): What the two endpoints do and where they stop: generation from JSON, validation against the KoSIT rule set, and no transmission, archiving or Peppol access point.− - [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 the KoSIT validator before it leaves; validation free and unlimited; processing in the EU, no storage; prices; one curl example.− - [Preise](https://normapi.de/preise): Tarife ab 19 € im Monat; 150.000 erzeugte Rechnungen im Jahr für 599 € im Monat. Die Prüfung ist in jedem Tarif kostenlos.− - [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 kostenlos; Preise und ein Beispielaufruf.− - [Startseite](https://normapi.de): Was die zwei Endpunkte tun und wo sie aufhören: aus JSON erzeugen, gegen das KoSIT-Regelwerk prüfen — kein Versand, keine Archivierung, kein Peppol-Zugangspunkt.+ > 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+ > 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.+ - [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 sa+ - [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 f+ - [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+ - [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.+ - [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.+ - [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.+ - [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.+ - [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.+ - [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.+ - [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.

https://normapi.com/llms.txt

− > hybrid ZUGFeRD PDFs.− - [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. Free, no account.− - [API documentation](https://normapi.com/en/docs): Endpoints, authentication, request and response shapes for validating and generating invoices — 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 — with curl and TypeScript examples.− - [Pricing](https://normapi.com/en/pricing): Flat monthly plans with an allowance of generated invoices: 25 a month free, 500 on Starter (€49), 2,500 on Business (€149), 6,000 on Scale (€299, then €0.05 per further invoice up to a monthly cap the customer sets; Starter and Business answer 402 past the allowance); paid yearly each costs ten months (€490, €1,490, €2,990). For volume from your own ERP: €599 a month for 150,000 generated invoices a year on a 12-month term (about €0.048 per invoice),− - [Preise](https://normapi.de/preise): Tarife ab 49 € im Monat; 150.000 erzeugte Rechnungen im Jahr für 599 € im Monat. Die Prüfung ist in jedem Tarif kostenlos.+ > hybrid ZUGFeRD PDFs, on our page or embedded in the caller’s own PDF.+ - [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 and generating invoices — 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, and a table of exactly+ - [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.05 per further invoice up to a monthly cap the customer sets, at most 30,000 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 f+ - [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 the KoSIT validator before it leaves; validation free and unlimited; processing in the EU, no storage; prices; one curl example.+ - [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.+ - [Preise](https://normapi.de/preise): Tarife ab 19 € im Monat; 150.000 erzeugte Rechnungen im Jahr für 599 € im Monat. Die Prüfung ist in jedem Tarif kostenlos.+ - [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 kostenlos; Preise und ein Beispielaufruf.+ - [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.