Skip to main content

einvoice_data_invalid

HTTP 422 · code: "einvoice_data_invalid" · type: https://docs.formfeed.dev/errors/einvoice-data-invalid

The render makes an e-invoice, and its invoice data cannot make a valid one. The answer comes from one of two places:

  • Before anything is rendered. The _invoice block of data is missing, a field is missing, a code is not in its list, or a total does not add up. errors lists every finding with its path, its message and, where one applies, the rule of EN 16931 or of the French specifications it breaks; detail repeats the first. Nothing is rendered, counted or charged. In a batch, index names the first item that failed, and nothing is queued.
  • After rendering. The block passed that check, and the validator still refused the finished file. The problem then carries einvoice, the report of the validator, and render_id. The render is failed and keeps the report. No file is stored, and no plain PDF is delivered instead. A failed render costs nothing.

Example​

Refused before rendering:

{
  "type": "https://docs.formfeed.dev/errors/einvoice-data-invalid",
  "title": "E-invoice data invalid",
  "status": 422,
  "detail": "_invoice.totals.grand is 1142.41, but tax_basis plus tax_total is 1142.40 (BR-CO-15) (and 1 more)",
  "code": "einvoice_data_invalid",
  "errors": [
    {
      "path": "data._invoice.totals.grand",
      "message": "_invoice.totals.grand is 1142.41, but tax_basis plus tax_total is 1142.40 (BR-CO-15)",
      "rule": "BR-CO-15"
    },
    {
      "path": "data._invoice.totals.due",
      "message": "_invoice.totals.due is 1142.40, but grand less prepaid plus rounding is 1142.41 (BR-CO-16)",
      "rule": "BR-CO-16"
    }
  ],
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Refused by the validator after rendering:

{
  "type": "https://docs.formfeed.dev/errors/einvoice-data-invalid",
  "title": "E-invoice data invalid",
  "status": 422,
  "detail": "The e-invoice breaks 1 rule of EN 16931",
  "code": "einvoice_data_invalid",
  "location": null,
  "render_id": "rnd_7da09ab6cd9946b798c187c2a9350852",
  "einvoice": {
    "profile": "en16931",
    "flavour": "factur-x",
    "spec_version": "1.09",
    "xml_url": null,
    "validation": {
      "valid": false,
      "schematron": "Factur-X 1.09.2 (Mustang 2.26.0)",
      "pdfa": null,
      "messages": [
        {
          "part": "xml",
          "severity": "error",
          "rule": "…",
          "message": "…",
          "location": "/rsm:CrossIndustryInvoice/…"
        }
      ]
    },
    "display": null
  },
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Common causes​

  • The data has no _invoice block. A template whose settings declare an e-invoice needs one in every PDF render (path is data._invoice).
  • A total that does not add up to the cent (BR-CO-10 to BR-CO-16), or a VAT breakdown that does not match the lines. Formfeed computes and rounds nothing for you.
  • An amount with more than two decimals, such as a line total that was never rounded.
  • A code that is not in its list: a unit written as hours instead of HUR (BR-CL-23), a country, a currency.
  • A field the standard asks for is missing: the due date or the payment terms of an invoice with an amount due (BR-CO-25), the IBAN of a credit transfer (BR-61), an identifier of the seller (BR-CO-26).
  • An invoice between two French businesses without the fields France asks for, or in the profile basic, which France's reform does not accept.
  • The profile basic with a totals.rounding other than 0, which that profile cannot carry.

How to fix it​

  • Fix the fields errors names. Paths start at data._invoice, and list items count from 0, so data._invoice.lines[0].unit_code is the unit of the first line. The field reference says what each field takes.
  • Find the findings before you send the request: the E-invoice section of the editor's Page setup lists them for the data set on screen, and formfeed validate checks every data set of a template offline. Both run the check the API runs.
  • When the problem carries einvoice, read einvoice.validation.messages: each finding has its rule and its location, an XPath into the XML. The failed render keeps the same report, in GET /v1/renders/{id} and in the render log. If the data looks right to you, send the render_id to support@formfeed.dev.
  • Which VAT category and rate apply to a sale is a question for your tax adviser. Formfeed checks only that the block is consistent with what you state.
  • If this request should produce a plain PDF from a template that declares an e-invoice, send "post": { "einvoice": false }.

Retry?​

No. Retrying the same request gives the same answer; change the data first. Send the corrected request with a new Idempotency-Key or without one: a 4xx answer is stored under its key for 24 hours, so the old key returns this problem again. See retrying.