---
title: "Read an invoice document into the JSON model"
method: POST
path: "/v1/parse"
tags: ["Invoices"]
---

# Read an invoice document into the JSON model

`POST /v1/parse`

## Request

- Base URL: `https://api.attestwire.com`
- URL: `https://api.attestwire.com/v1/parse`
- Auth: HTTP bearer

Reads a UBL 2.1 or UN/CEFACT CII invoice document — or the CII invoice attached to a Factur-X or ZUGFeRD PDF — into `InvoiceInput` and stops there. **No verdict is given.**

THE FIRST TASK ON AN ERP INTEGRATION. Before anything can be validated, edited, stored or re-emitted, somebody has to get from a supplier's XML to an object. POST /v1/validate has read documents for a while, but it returns a verdict and throws the model away — so this returns the model. The `invoice` that comes back is the exact shape POST /v1/validate and POST /v1/generate accept, so parsing a UBL file and generating CII from the result is a syntax conversion with no mapping code of your own.

It is the SAME reader as the document half of /v1/validate, through the same module and the same engine call: a document that parses here parses identically there, and the model you get back is the model that would have been judged.

**A `200` is not a verdict.** It means the file parsed. A document that comes back cleanly can still break every rule EN 16931 has — send `invoice` to POST /v1/validate for the answer to that, which is a second document against your allowance.

**Documents only**, which inverts the default everywhere else here: this endpoint needs `application/xml` or `text/xml` for XML, `application/pdf` for a Factur-X or ZUGFeRD PDF, or `application/octet-stream` for either. Anything else is `415 unsupported_media_type`, with a message that names what the body is and the content-type that works; a JSON body is refused because there would be nothing to parse. For a PDF, `container` names the attachment the XML was read from. No finding is returned here, the PDF's own included: POST /v1/validate reports the attachment and the XMP metadata as AW-PDF-* findings, and PDF/A conformance itself, and whether the page agrees with the XML, are not checked by either endpoint.

METERING: one document once the file has been read, on exactly the terms /v1/validate charges — reading is the work. A file that cannot be read at all (`400`, `413`, `415`) costs nothing and carries the unchanged `X-RateLimit-*` set.

## Query parameters

- `max_characters` integer

## Response `200`

The document was read. One document was charged. No verdict is given.

- ParseResult: The body of POST /v1/parse: a document read into the model, and nothing judged. There is no `valid` field here and that is deliberate — a response that carried one would be answering a question no rule was asked.
  - `syntax` 'ubl' | 'cii', required: Which reader ran, decided from the root element of the document you sent.
  - `container` string, nullable, required: When a Factur-X or ZUGFeRD PDF was sent: the name of the attachment the XML was read from. `null` for an XML file.
  - `customizationId` string, nullable, required: BT-24, exactly as the document states it — not as we would have written it. `invoice.profile` is derived from this. `null` when the document states none.
  - `profileId` string, nullable, required: BT-23, exactly as the document states it. `null` when it states none.
  - `invoice` InvoiceInput, required: The invoice as JSON: the body of POST /v1/validate (as `application/json`) and of POST /v1/generate, and the `invoice` POST /v1/parse returns. Field names map to EN 16931 business terms. The fields in `required` are the only ones the model needs; every other field and group is optional, and one you leave out is not written. Types are the model's and nothing more: the rules judge the values and report what is wrong as findings, so a value this schema allows can still fail validation. Mirrors `InvoiceInput` in @attestwire/en16931.
    - `profile` 'en16931' | 'xrechnung-ubl' | 'xrechnung-cii' | 'facturx-en16931' | 'peppol-bis-3' | 'auto', required: Selects the rule set, and on POST /v1/generate the syntax. Narrower profiles add rules; they never remove core ones. "auto" (POST /v1/validate and /v1/generate) has the API choose from the buyer, without any network call: a Leitweg-ID (electronic address scheme 0204, or a German buyer reference) is xrechnung-ubl; a Belgian buyer or a Peppol electronic address is peppol-bis-3; a French buyer is facturx-en16931; a German or Austrian business is xrechnung-cii, or facturx-en16931 with ?format=pdf; anything else is en16931 (facturx-en16931 with ?format=pdf). The answer names the choice and the rule in `profile_choice` and the Attestwire-Profile headers.
    - `invoiceNumber` string, required: BT-1 invoice number.
    - `issueDate` string, date, required: BT-2 issue date, ISO 8601.
    - `currency` string, required: BT-5 invoice currency code, ISO 4217.
    - `invoiceTypeCode` string: BT-3 document type code, UNTDID 1001: "380", the default, is a commercial invoice and "381" a credit note. It decides the document type: "381" makes a UBL `CreditNote` or a CII document with type code 381, from the same fields. State a credit note's amounts positively; the type code carries the direction. BR-DE-17 restricts XRechnung to 326/380/381/384/389/875/876/877.
    - `dueDate` string, date: BT-9 payment due date, ISO 8601. A UBL credit note carries it inside the payment means (`cac:PaymentMeans/cbc:PaymentDueDate`), so there it needs `payment`; without that group it is dropped and reported as ATW-CREDIT-NOTE-DUE-DATE-UNBOUND.
    - `note` string: BT-22 invoice note, free text.
    - `noteSubjectCode` string: BT-21 invoice note subject code, UNCL 4451. Written into the note itself as `#CODE#text`, so it only means something when `note` is set.
    - `buyerReference` string: BT-10 buyer reference, which XRechnung requires (BR-DE-15). A German public-sector buyer's is its Leitweg-ID.
    - `orderReference` string: BT-13 purchase order reference.
    - `salesOrderReference` string: BT-14 sales order reference: your own order number, not the buyer's.
    - `projectReference` string: BT-11 project reference. `UBL-CreditNote-2.1.xsd` has no element for it, so on a UBL credit note it is dropped and reported as ATW-CREDIT-NOTE-PROJECT-REFERENCE-UNBOUND. CII keeps it.
    - `contractReference` string: BT-12 contract reference.
    - `despatchAdviceReference` string: BT-16 despatch advice reference.
    - `receivingAdviceReference` string: BT-15 receiving advice reference.
    - `tenderOrLotReference` string: BT-17 tender or lot reference.
    - `invoicedObjectIdentifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
      - `value` string, required: The identifier.
      - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
    - `buyerAccountingReference` string: BT-19 buyer accounting reference: the buyer's cost centre or ledger account.
    - `taxPointDate` string, date: BT-7 value added tax point date, ISO 8601. BR-CO-03 does not allow it together with `invoicingPeriod.descriptionCode` (BT-8).
    - `invoicingPeriod` InvoicingPeriod: BG-14 invoicing period, or BG-26 when it is a line's `period`. The first term of each pair is the document's.
      - `startDate` string, date: BT-73 / BT-134 period start date, ISO 8601.
      - `endDate` string, date: BT-74 / BT-135 period end date, ISO 8601.
      - `descriptionCode` string: BT-8 value added tax point date code, UNTDID 2005 (3, 35 or 432). Document level only: ignored on a line period. BR-CO-03 does not allow it together with `taxPointDate`.
    - `precedingInvoices` PrecedingInvoiceReference[]: BG-3 preceding invoice references: the invoices this document corrects, credits or settles against. BR-DE-26 requires one for a corrected invoice (BT-3 = 384). A credit note is not required to carry one; leaving it out raises ATW-CREDIT-NOTE-NO-PRECEDING-INVOICE at severity `information`.
      - `invoiceNumber` string, required: BT-25 the number of the invoice being corrected or referenced.
      - `issueDate` string, date: BT-26 the issue date of that invoice, ISO 8601.
    - `seller` Party, required: BG-4 seller or BG-7 buyer. Where a field names two terms, the first is the seller's and the second the buyer's; a field with one term exists for the seller only.
      - `name` string, required: BT-27 / BT-44 name, written as both the legal name and the trading name (BT-28 / BT-45) unless `legalName` or `tradingName` says otherwise.
      - `vatId` string: BT-31 / BT-48 VAT identifier, with its country prefix.
      - `taxRegistrationId` string: BT-32 seller tax registration identifier, such as the German Steuernummer.
      - `legalRegistrationId` string: BT-30 / BT-47 legal registration identifier, such as an HRB number.
      - `legalRegistrationSchemeId` string: BT-30-1 / BT-47-1 ISO 6523 ICD scheme of the legal registration identifier.
      - `identifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
        - `value` string, required: The identifier.
        - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
      - `additionalLegalInformation` string: BT-33 seller additional legal information: legal form, share capital and the like.
      - `tradingName` string: BT-28 / BT-45 trading name, when the party trades under a name other than its legal one.
      - `legalName` string: BT-27 / BT-44 registered legal name, when it differs from `name`.
      - `address` PostalAddress, required: A postal address: BG-5 seller, BG-8 buyer or BG-12 tax representative. The terms are listed in that order.
        - `line1` string: BT-35 / BT-50 / BT-64 address line 1.
        - `line2` string: BT-36 / BT-51 / BT-65 address line 2.
        - `line3` string: BT-162 / BT-163 / BT-164 address line 3.
        - `city` string, required: BT-37 / BT-52 / BT-66 city.
        - `postalCode` string, required: BT-38 / BT-53 / BT-67 post code.
        - `countrySubdivision` string: BT-39 / BT-54 / BT-68 country subdivision: a Bundesland, a région, a county.
        - `countryCode` string, required: BT-40 / BT-55 / BT-69 country code, ISO 3166-1 alpha-2.
      - `electronicAddress` ElectronicAddress: BT-34 seller or BT-49 buyer electronic address: where the network delivers the document. Both halves are required.
        - `schemeId` string, required: BT-34-1 / BT-49-1 scheme identifier, from the Peppol EAS code list.
        - `value` string, required: BT-34 / BT-49 the address itself.
      - `contact` Contact: BG-6 seller contact or BG-9 buyer contact.
        - `name` string: BT-41 / BT-56 contact point: a person or a department.
        - `email` string: BT-43 / BT-58 contact email address.
        - `phone` string: BT-42 / BT-57 contact telephone number.
    - `buyer` Party, required: BG-4 seller or BG-7 buyer. Where a field names two terms, the first is the seller's and the second the buyer's; a field with one term exists for the seller only.
      - `name` string, required: BT-27 / BT-44 name, written as both the legal name and the trading name (BT-28 / BT-45) unless `legalName` or `tradingName` says otherwise.
      - `vatId` string: BT-31 / BT-48 VAT identifier, with its country prefix.
      - `taxRegistrationId` string: BT-32 seller tax registration identifier, such as the German Steuernummer.
      - `legalRegistrationId` string: BT-30 / BT-47 legal registration identifier, such as an HRB number.
      - `legalRegistrationSchemeId` string: BT-30-1 / BT-47-1 ISO 6523 ICD scheme of the legal registration identifier.
      - `identifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
        - `value` string, required: The identifier.
        - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
      - `additionalLegalInformation` string: BT-33 seller additional legal information: legal form, share capital and the like.
      - `tradingName` string: BT-28 / BT-45 trading name, when the party trades under a name other than its legal one.
      - `legalName` string: BT-27 / BT-44 registered legal name, when it differs from `name`.
      - `address` PostalAddress, required: A postal address: BG-5 seller, BG-8 buyer or BG-12 tax representative. The terms are listed in that order.
        - `line1` string: BT-35 / BT-50 / BT-64 address line 1.
        - `line2` string: BT-36 / BT-51 / BT-65 address line 2.
        - `line3` string: BT-162 / BT-163 / BT-164 address line 3.
        - `city` string, required: BT-37 / BT-52 / BT-66 city.
        - `postalCode` string, required: BT-38 / BT-53 / BT-67 post code.
        - `countrySubdivision` string: BT-39 / BT-54 / BT-68 country subdivision: a Bundesland, a région, a county.
        - `countryCode` string, required: BT-40 / BT-55 / BT-69 country code, ISO 3166-1 alpha-2.
      - `electronicAddress` ElectronicAddress: BT-34 seller or BT-49 buyer electronic address: where the network delivers the document. Both halves are required.
        - `schemeId` string, required: BT-34-1 / BT-49-1 scheme identifier, from the Peppol EAS code list.
        - `value` string, required: BT-34 / BT-49 the address itself.
      - `contact` Contact: BG-6 seller contact or BG-9 buyer contact.
        - `name` string: BT-41 / BT-56 contact point: a person or a department.
        - `email` string: BT-43 / BT-58 contact email address.
        - `phone` string: BT-42 / BT-57 contact telephone number.
    - `payee` Payee: BG-10 payee: where the money goes, when that is not the seller.
      - `name` string, required: BT-59 payee name. Must differ from the seller name (BR-17).
      - `identifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
        - `value` string, required: The identifier.
        - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
      - `legalRegistrationId` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
        - `value` string, required: The identifier.
        - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
    - `taxRepresentative` TaxRepresentative: BG-11 seller tax representative party.
      - `name` string, required: BT-62 tax representative name.
      - `vatId` string, required: BT-63 tax representative VAT identifier. BR-56 requires it once BG-11 exists.
      - `address` PostalAddress, required: A postal address: BG-5 seller, BG-8 buyer or BG-12 tax representative. The terms are listed in that order.
        - `line1` string: BT-35 / BT-50 / BT-64 address line 1.
        - `line2` string: BT-36 / BT-51 / BT-65 address line 2.
        - `line3` string: BT-162 / BT-163 / BT-164 address line 3.
        - `city` string, required: BT-37 / BT-52 / BT-66 city.
        - `postalCode` string, required: BT-38 / BT-53 / BT-67 post code.
        - `countrySubdivision` string: BT-39 / BT-54 / BT-68 country subdivision: a Bundesland, a région, a county.
        - `countryCode` string, required: BT-40 / BT-55 / BT-69 country code, ISO 3166-1 alpha-2.
    - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened, in business terms, for every line, document level allowance and charge that does not say otherwise: the engine writes the VAT category (BT-151, BT-95, BT-102), the rate and the exemption reason (BT-120, BT-121) from it. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes. An item's own `vatScenario` or `vatCategory` overrides this default. The document is byte for byte the one the explicit codes produce.
    - `lines` InvoiceLine[], required: BG-25 invoice lines, at least one (BR-16). An empty list is answered with that finding.
      - `id` string, required: BT-126 invoice line identifier.
      - `description` string, required: BT-153 item name.
      - `longDescription` string: BT-154 item description, when it should say more than the item name.
      - `quantity` number, required: BT-129 invoiced quantity.
      - `unitCode` string, required: BT-130 unit of measure code, UN/ECE Recommendation 20.
      - `unitPrice` number, required: BT-146 item net price.
      - `grossUnitPrice` number: BT-148 item gross price, before the BT-147 price discount.
      - `priceDiscount` number: BT-147 item price discount: the difference between BT-148 and BT-146.
      - `baseQuantity` number: BT-149 item price base quantity, 1 when absent.
      - `vatCategory` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M', required: BT-151 invoiced item VAT category code, UNCL 5305: S standard rate, Z zero rated, E exempt, AE reverse charge, K intra-community supply, G export outside the EU, O not subject to VAT, L IGIC (Canary Islands), M IPSI (Ceuta and Melilla). Left out, it comes from the line's `vatScenario` or the invoice's.
      - `vatRate` number: BT-152 invoiced item VAT rate, in percent.
      - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened on this line, instead of its VAT code: the engine writes `vatCategory`, the rate (except for "domestic", whose rate you give in `vatRate`) and the exemption reason from it. It overrides the invoice's `vatScenario`. A `vatCategory` stated beside it must be the one it stands for: disagreeing is the fatal ATW-VAT-SCENARIO-CONFLICT. With a scenario, `vatCategory` may be left out of the request although this schema lists it as required (the schema describes the explicit model, which POST /v1/parse returns); the response reports each code it filled in as ATW-VAT-SCENARIO-APPLIED, at severity information. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes.
      - `note` string: BT-127 invoice line note.
      - `objectIdentifier` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
        - `value` string, required: The identifier.
        - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
      - `buyerAccountingReference` string: BT-133 invoice line buyer accounting reference.
      - `period` InvoicingPeriod: BG-14 invoicing period, or BG-26 when it is a line's `period`. The first term of each pair is the document's.
        - `startDate` string, date: BT-73 / BT-134 period start date, ISO 8601.
        - `endDate` string, date: BT-74 / BT-135 period end date, ISO 8601.
        - `descriptionCode` string: BT-8 value added tax point date code, UNTDID 2005 (3, 35 or 432). Document level only: ignored on a line period. BR-CO-03 does not allow it together with `taxPointDate`.
      - `orderLineReference` string: BT-132 referenced purchase order line reference.
      - `allowances` LineAllowanceCharge[]: BG-27 invoice line allowances: discounts on this line only.
        - `amount` number, required: BT-136 / BT-141 amount, always positive.
        - `baseAmount` number: BT-137 / BT-142 base amount.
        - `percentage` number: BT-138 / BT-143 percentage.
        - `reason` string: BT-139 / BT-144 reason, free text.
        - `reasonCode` string: BT-140 / BT-145 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge.
      - `charges` LineAllowanceCharge[]: BG-28 invoice line charges: surcharges on this line only.
        - `amount` number, required: BT-136 / BT-141 amount, always positive.
        - `baseAmount` number: BT-137 / BT-142 base amount.
        - `percentage` number: BT-138 / BT-143 percentage.
        - `reason` string: BT-139 / BT-144 reason, free text.
        - `reasonCode` string: BT-140 / BT-145 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge.
      - `sellerItemId` string: BT-155 item seller's identifier.
      - `buyerItemId` string: BT-156 item buyer's identifier.
      - `standardItemId` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
        - `value` string, required: The identifier.
        - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
      - `itemClassifications` ItemClassification[]: BT-158 item classification identifiers.
        - `code` string, required: BT-158 the classification code.
        - `schemeId` string, required: BT-158-1 the scheme it is drawn from, UNTDID 7143.
        - `schemeVersion` string: BT-158-2 the version of that scheme.
      - `originCountryCode` string: BT-159 item country of origin, ISO 3166-1 alpha-2.
      - `itemAttributes` ItemAttribute[]: BG-32 item attributes: name and value pairs describing the item.
        - `name` string, required: BT-160 item attribute name.
        - `value` string, required: BT-161 item attribute value.
    - `allowances` DocumentAllowanceCharge[]: BG-20 document level allowances: discounts on the whole invoice.
      - `amount` number, required: BT-92 / BT-99 amount, always positive.
      - `baseAmount` number: BT-93 / BT-100 base amount.
      - `percentage` number: BT-94 / BT-101 percentage.
      - `vatCategory` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M', required: BT-95 / BT-102 VAT category code, UNCL 5305: S standard rate, Z zero rated, E exempt, AE reverse charge, K intra-community supply, G export outside the EU, O not subject to VAT, L IGIC (Canary Islands), M IPSI (Ceuta and Melilla). Left out, it comes from the entry's `vatScenario` or the invoice's.
      - `vatRate` number: BT-96 / BT-103 VAT rate, in percent.
      - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened, instead of the VAT code of this allowance or charge: the engine writes `vatCategory`, the rate (except for "domestic", whose rate you give in `vatRate`) and the exemption reason from it. It overrides the invoice's `vatScenario`. A `vatCategory` stated beside it must be the one it stands for: disagreeing is the fatal ATW-VAT-SCENARIO-CONFLICT. With a scenario, `vatCategory` may be left out of the request although this schema lists it as required (the schema describes the explicit model, which POST /v1/parse returns); the response reports each code it filled in as ATW-VAT-SCENARIO-APPLIED, at severity information. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes.
      - `reason` string: BT-97 / BT-104 reason, free text.
      - `reasonCode` string: BT-98 / BT-105 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge.
    - `charges` DocumentAllowanceCharge[]: BG-21 document level charges: freight, packing, surcharges.
      - `amount` number, required: BT-92 / BT-99 amount, always positive.
      - `baseAmount` number: BT-93 / BT-100 base amount.
      - `percentage` number: BT-94 / BT-101 percentage.
      - `vatCategory` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M', required: BT-95 / BT-102 VAT category code, UNCL 5305: S standard rate, Z zero rated, E exempt, AE reverse charge, K intra-community supply, G export outside the EU, O not subject to VAT, L IGIC (Canary Islands), M IPSI (Ceuta and Melilla). Left out, it comes from the entry's `vatScenario` or the invoice's.
      - `vatRate` number: BT-96 / BT-103 VAT rate, in percent.
      - `vatScenario` 'domestic' | 'intra-eu-goods' | 'intra-eu-services' | 'export' | 'small-business-exemption': What happened, instead of the VAT code of this allowance or charge: the engine writes `vatCategory`, the rate (except for "domestic", whose rate you give in `vatRate`) and the exemption reason from it. It overrides the invoice's `vatScenario`. A `vatCategory` stated beside it must be the one it stands for: disagreeing is the fatal ATW-VAT-SCENARIO-CONFLICT. With a scenario, `vatCategory` may be left out of the request although this schema lists it as required (the schema describes the explicit model, which POST /v1/parse returns); the response reports each code it filled in as ATW-VAT-SCENARIO-APPLIED, at severity information. "domestic": a taxed sale inside the seller's own country — category S at the rate you state in `vatRate`, which is never guessed. "intra-eu-goods": goods shipped to a VAT-registered business in another EU member state — K, rate 0, VATEX-EU-IC; the invoice also needs both parties' VAT identifiers, `deliverTo.countryCode` and a delivery date or invoicing period. "intra-eu-services": a service to a business in another EU member state, which accounts for the VAT itself (reverse charge) — AE, rate 0, VATEX-EU-AE; needs both VAT identifiers. "export": goods leaving the EU — G, rate 0, VATEX-EU-G; needs the seller's VAT identifier. "small-business-exemption": the seller does not charge VAT under its small-business scheme, Germany's § 19 UStG or France's franchise en base — E, rate 0, with the wording each country prescribes; a seller elsewhere is refused with ATW-VAT-SCENARIO-UNSUPPORTED. The exemption text is written in German for a seller in DE or AT, in French for FR, in English otherwise. It is not a tax determination: you decide which scenario applies, and the engine only writes its codes.
      - `reason` string: BT-97 / BT-104 reason, free text.
      - `reasonCode` string: BT-98 / BT-105 reason code: UNCL 5189 for an allowance, UNCL 7161 for a charge.
    - `paymentTerms` string: BT-20 payment terms, free text.
    - `payment` PaymentInstructions: BG-16 payment instructions. Required for XRechnung profiles by BR-DE-1.
      - `meansCode` string, required: BT-81 payment means type code, UNTDID 4461: "58" SEPA credit transfer, "30" credit transfer, "59" SEPA direct debit, "48" card, "57" standing order, "97" clearing. Left out of a request, it is inferred from the account, as the engine's `applyDefaults` does: "59" for a direct debit mandate in euro and "49" in another currency, else "58" for an IBAN in the SEPA scheme paid in euro and "30" for any other IBAN; the response reports it as ATW-PAYMENT-MEANS-INFERRED, at severity information.
      - `meansName` string: BT-82 payment means text.
      - `iban` string: BT-84 payment account identifier (BG-17): the IBAN, for a credit transfer.
      - `accountName` string: BT-85 payment account name (BG-17).
      - `bic` string: BT-86 payment service provider identifier (BG-17): the BIC.
      - `remittanceInformation` string: BT-83 remittance information: the payment reference.
      - `card` PaymentCard: BG-18 payment card information.
        - `primaryAccountNumber` string, required: BT-87 payment card primary account number: at most its first six and last four digits. BR-51 warns above ten characters; never put a full card number on an invoice.
        - `holderName` string: BT-88 payment card holder name.
      - `directDebit` DirectDebit: BG-19 direct debit information.
        - `mandateReference` string: BT-89 mandate reference identifier.
        - `creditorIdentifier` string: BT-90 bank assigned creditor identifier: the SEPA creditor identifier. Written as the seller's identifier with scheme "SEPA", where BR-DE-30 looks for it.
        - `debitedAccount` string: BT-91 debited account identifier: the payer's IBAN. Required by BR-DE-31.
    - `supportingDocuments` SupportingDocument[]: BG-24 additional supporting documents.
      - `reference` string, required: BT-122 supporting document reference.
      - `description` string: BT-123 supporting document description.
      - `externalUri` string: BT-124 external document location: a URL.
      - `attachment` EmbeddedAttachment: BT-125 attached document, embedded in the invoice.
        - `filename` string, required: BT-125-2 attached document filename. Must be unique across the invoice (BR-DE-22).
        - `mimeCode` string, required: BT-125-1 attached document MIME code. BR-CL-24 admits only application/pdf, image/png, image/jpeg, text/csv, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet and application/vnd.oasis.opendocument.spreadsheet.
        - `content` string, required: BT-125 the document bytes, base64-encoded. Written as given, not re-encoded.
    - `deliveryDate` string, date: BT-72 actual delivery date, ISO 8601. Required with BT-80 by BR-IC-11 for category K. On XRechnung profiles, an invoice with no time of supply at all (no BT-72, no `invoicingPeriod`, no line `period`) raises BR-DE-TMP-32 at severity `information`.
    - `deliverTo` DeliverToAddress: BG-15 deliver-to address. Only the country code is required by the model; XRechnung also requires the city and post code once the group is present.
      - `line1` string: BT-75 deliver-to address line 1.
      - `line2` string: BT-76 deliver-to address line 2.
      - `city` string: BT-77 deliver-to city. Mandatory under XRechnung once BG-15 is present.
      - `postalCode` string: BT-78 deliver-to post code. Mandatory under XRechnung once BG-15 is present.
      - `countrySubdivision` string: BT-79 deliver-to country subdivision.
      - `countryCode` string, required: BT-80 deliver-to country code, ISO 3166-1 alpha-2.
    - `deliverToName` string: BT-70 deliver-to party name.
    - `deliverToLocationId` SchemedIdentifier: An identifier with its scheme. The field that holds it names the business term, and which code list the scheme comes from.
      - `value` string, required: The identifier.
      - `schemeId` string: Its scheme identifier: ISO 6523 ICD for party, location and item identifiers, UNTDID 1153 for the invoiced object and line object identifiers.
    - `vatAccountingCurrency` string: BT-6 VAT accounting currency, ISO 4217, when VAT is reported in a currency other than BT-5. Supplying it obliges you to supply `taxAmountInAccountingCurrency` (BR-53).
    - `taxAmountInAccountingCurrency` number: BT-111 invoice total VAT amount in the VAT accounting currency. It depends on the exchange rate the tax authority requires for the tax point, which is not on the invoice, so it cannot be derived: you supply it.
    - `paidAmount` number: BT-113 paid amount: a prepayment or deposit already received. It is subtracted from the amount due (BT-115).
    - `roundingAmount` number: BT-114 rounding amount, added to the total to produce a payable round figure.
    - `vatExemptionReasons` object: BT-120 VAT exemption reason text, keyed by VAT category, such as `{"E": "…"}`. Defaults are applied for AE, K, G and O; category E has no standard text, so BR-E-10 requires you to supply one.
    - `vatExemptionReasonCodes` object: BT-121 VAT exemption reason code from the CEF VATEX list, keyed by VAT category.
    - `declaredTotals` DeclaredTotals: Totals as someone else computed them, checked against the computed ones under BR-CO-10/11/12/13/14/15/16. Generation always writes the computed values: these exist so you can catch a mismatch in your own accounting system before a tax authority does, and omitting one is never an error. The readers (POST /v1/parse, and POST /v1/validate with a document) also record here what a document states, including the fields described as set by the readers, which a caller building the model leaves out. On that path a document must state its totals: one that omits BT-106, BT-109, BT-112 or BT-115 fails BR-12, BR-13, BR-14 or BR-15, and one that states a total that cannot be read as a number fails ATW-DECLARED-TOTAL-NOT-A-NUMBER.
      - `syntax` 'ubl' | 'cii': Set by the readers: the syntax the document was read from. It decides how BR-S-08 and its per-category siblings compare the stated taxable amount: exactly in CII, within ±1 in UBL.
      - `taxTotalsInInvoiceCurrency` number: Set by the readers: how many VAT totals carry the invoice currency (BT-5). BR-CO-15 requires exactly one.
      - `specificationIdentifier` string: BT-24 specification identifier as the document states it, trimmed; empty when absent. Set by the readers, so BR-01 can be judged.
      - `lineNetAmounts` number[]: BT-131 invoice line net amounts as each line states them, in document order; null where a line states none. Set by the readers.
      - `subtotals` DeclaredTaxSubtotal[]: BG-23 VAT breakdown as the document states it, in document order. Set by the readers.
        - `category` 'S' | 'Z' | 'E' | 'AE' | 'K' | 'G' | 'O' | 'L' | 'M': BT-118 VAT category code, as written.
        - `rate` number: BT-119 VAT category rate, as written.
        - `taxableAmount` number: BT-116 VAT category taxable amount, as written.
        - `taxAmount` number: BT-117 VAT category tax amount, as written.
      - `lineExtensionAmount` number: BT-106 sum of invoice line net amounts.
      - `allowanceTotalAmount` number: BT-107 sum of allowances on document level.
      - `chargeTotalAmount` number: BT-108 sum of charges on document level.
      - `taxExclusiveAmount` number: BT-109 invoice total amount without VAT.
      - `taxAmount` number: BT-110 invoice total VAT amount.
      - `taxInclusiveAmount` number: BT-112 invoice total amount with VAT.
      - `payableAmount` number: BT-115 amount due for payment.
      - `defects` DeclaredTotalDefect[]: Set by the readers: document totals the document was supposed to state and did not state readably, one entry per term. On the JSON model an omitted total means "compute it" and is never a defect.
        - `key` 'lineExtensionAmount' | 'allowanceTotalAmount' | 'chargeTotalAmount' | 'taxExclusiveAmount' | 'taxAmount' | 'taxInclusiveAmount' | 'payableAmount' | 'taxAmountInAccountingCurrency', required: Which total it is, as a key of DeclaredTotals. `taxAmountInAccountingCurrency` names BT-111, which the model carries on the invoice itself.
        - `field` string, required: The business term, such as BT-115.
        - `state` 'absent' | 'empty' | 'unreadable', required: Why it could not be read: `absent` fails a BR presence rule, while `empty` and `unreadable` fail XML Schema validation at the official validator before any business rule, and this API reports them as ATW-DECLARED-TOTAL-NOT-A-NUMBER.
        - `text` string: What the element held, verbatim, cut at 200 characters. Only for `unreadable`.
        - `xpath` string, required: Where the value is in the document, or where it should have been.
      - `overPrecise` OverPreciseAmount[]: Set by the readers: amounts the document wrote with more than two decimal places, in document order, which the BR-DEC rules report.
        - `field` string, required: The business term, which selects the BR-DEC rule.
        - `decimals` number, required: Digits after the decimal point, trailing zeros included.
        - `text` string, required: The amount exactly as the document writes it.
        - `xpath` string, required: Where it was found.
        - `line` number: 1-based invoice line, for a line-level term (BT-131).
        - `group` number: 1-based VAT breakdown group, for BT-116 and BT-117.
  - `unmapped` UnmappedElement[], required: The parse-level findings: everything in the document that did not reach the model. SILENT DATA LOSS ON A TAX DOCUMENT IS THE WORST POSSIBLE FAILURE, so this is reported rather than swallowed. `[]` when the whole document was understood.
    - `path` string, required: Path from the root, with a `[n]` index on repeated siblings.
    - `name` string, required: Qualified name as the document writes it.
    - `namespace` string, required: Namespace URI of the element.
    - `kind` 'unknown' | 'recomputed', required: `unknown` — there is no field for it, so THE CONTENT IS GONE from the model and from this validation. If it matters, read it out of the XML yourself. `recomputed` — the element is understood, but the model derives the value from the lines rather than storing it (line net amounts, the VAT breakdown). Nothing is lost.
    - `reason` string, required: Why it did not reach the model.
    - `text` string: Text content of the element, when it had any.
  - `unmapped_truncated` UnmappedTruncated: Present ONLY when the `unmapped` array was cut, and absent otherwise. One entry per invoice line is normal — line net amounts are recomputed — so a very long document produces a very long list that helps nobody. The validation itself is unaffected.
    - `total` integer, required: Unmapped elements the reader found.
    - `returned` integer, required: Unmapped elements listed in this response.
    - `cap` integer, required: The cap this deployment applied.
    - `note` string, required
  - `source` string, required: One sentence saying that the document was converted and NOT judged, and where to send it for the verdict — and, for a PDF, which attachment was read.
  - `provenance` Provenance: What ran. Present on every metered response — POST /v1/validate and POST /v1/parse, JSON body or XML document, and the JSON envelope of POST /v1/generate including the `422` it returns for an invoice it will not emit. WHY IT EXISTS. Pin `@attestwire/en16931` and your CI gets the same answer for the same invoice forever; the hosted API always runs the current rule set, because a compliance service that froze its rules would be answering last quarter's regulation. Both are correct and the difference used to be invisible — a `valid: false` looked identical whether your invoice had changed or our rules had. This says which. The one metered response WITHOUT it is `/v1/generate?format=xml`, which returns the document alone: an XML file has nowhere to put this, and this API does not write its own metadata into a customer's tax document.
    - `engine` string, required: The npm package every compliance decision on this API comes from. Install this package at `engine_version` and you have the build that judged your document.
    - `engine_version` string, required
    - `ruleset` string, required: The standard and our build of it, as one identifier to quote.
    - `profile` string, nullable, required: The CIUS that ACTUALLY ran, read from the result rather than from your request: a body naming no profile is judged as `en16931`, and this is where you see that. `null` when there was no verdict to read it from.
    - `kosit_conformance` KositConformance, required: When the official KoSIT validator was last run against this engine's committed fixtures, and with what. **NOTHING IS SENT TO KoSIT WHEN YOU CALL US.** This is a dated record of a check we ran on release, not a per-call verification, and it says nothing about YOUR document.
      - `recorded` string, date, required: The date of the last recorded full fixture run.
      - `validator` string, required: Version of the KoSIT standalone validator used.
      - `configuration` string, required: Version of the XRechnung validator configuration used.
      - `configuration_published` string, date, required: The date that configuration was published by KoSIT.

## Other responses

- `400`: The document could not be read. `xml_malformed` — not well-formed, or outside the XML subset the reader accepts (for a PDF, the XML attached to it). `xml_rejected` — well-formed but carrying a DOCTYPE or an entity declaration, refused on sight. `pdf_unreadable` — a PDF that cannot be read: truncated, corrupt, encrypted, or compressed with a filter the reader does not implement. `bad_request` — an empty body, or a `max_characters` value that is not a positive whole number at or below 16,000,000. The three document codes carry `xml_code` with the reader's own finer-grained code. Nothing was charged.
- `401`: Missing or unknown API key.
- `410`: The key presented was retired by an earlier rotation. Its replacement is the live credential; this one is permanently gone, so retrying with it cannot work. Every authenticated endpoint answers this, not just /v1/keys/rotate.
- `413`: The request body is over 1 MB. Nothing was read and nothing was charged. A document sent as `application/pdf` or `application/octet-stream` may be up to 10 MB, because a Factur-X file carries its fonts and images; `?max_characters` does not move that ceiling. Two narrower refusals are for a document inside its ceiling: `xml_limit_exceeded`, when the XML trips the reader's depth (100), element (50,000), attribute (256) or character (8,000,000) cap, and `pdf_limit_exceeded`, when a PDF is past one of the PDF reader's fixed limits (4 MB for any one stream once inflated, 8 MB for all of them, 4 MB for the XML attached) — most often a deflate bomb. `xml_code` says which cap or limit. Both carry the unchanged `X-RateLimit-*` set, because nothing was charged.
- `415`: Two codes, and they are different mistakes. `unsupported_media_type` — the request was not sent with a document content-type, so it was not read as one; the message names what the body is (XML, a PDF, a form upload, JSON) and the content-type that works. If you already hold the JSON model, POST /v1/validate is the endpoint you want. `unsupported_syntax` — the body IS a file, and not an invoice document this reader takes: an XML root that is none of ours (a `ubl:DebitNote`), a PDF with no XML invoice attached, an HTML page. Neither charges a document. The `X-RateLimit-*` set is present on `unsupported_syntax` and absent on `unsupported_media_type`, and the difference is not cosmetic: the media type is refused before the allowance is read, so there is no quota state to report and inventing it would be worse than omitting it.
- `429`: Refused for pace or for allowance. `error: "quota_exceeded"` — the monthly document allowance is exhausted, and the counter resets at 00:00 UTC on the 1st. `error: "rate_limited"` — too many requests per second on this key; retry after the number of seconds in `Retry-After` and the same request will succeed. Nothing is charged in either case.
- `500`: Unhandled fault while parsing a document. Never expected; the body carries no detail on purpose (a fault message can quote the offending value). Retry, and email hello@attestwire.com if it persists.

---

[API](https://skmtc.dev/attestwire/apis/attestwire-api.md) · [All operations](https://skmtc.dev/attestwire/apis/attestwire-api/llms.txt) · [OpenAPI document](https://skmtc.dev/attestwire/apis/attestwire-api/revisions/0036f8e043b2?raw)