Skip to main content

pdfa_validation_failed

HTTP 422 · code: "pdfa_validation_failed" · type: https://docs.formfeed.dev/errors/pdfa-validation-failed

The validator judged the converted file and found that it breaks rules of PDF/A. It is the error of two kinds of render:

  • a render with pdf.pdfa, which asked for a PDF/A-2b or PDF/A-3b;
  • an e-invoice, which is a PDF/A-3b that carries the invoice as XML.

The render is failed; no file is stored, no ordinary PDF is delivered instead, and a failed render costs nothing.

The problem carries the validator's report:

  • pdfa, for a render with pdf.pdfa. Its messages name the clause of PDF/A (rule) and the object of the PDF (location). An e-invoice that set pdf.pdfa carries it beside einvoice. The failed render keeps the same report.
  • einvoice, for an e-invoice. Its validation.messages with "part": "pdf" name the clause of PDF/A and the object of the PDF.

Example​

A render with "pdf": { "pdfa": "3b" }:

{
  "type": "https://docs.formfeed.dev/errors/pdfa-validation-failed",
  "title": "PDF/A validation failed",
  "status": 422,
  "detail": "The PDF could not be made a valid PDF/A-3b: 1 finding",
  "code": "pdfa_validation_failed",
  "location": null,
  "render_id": "rnd_7da09ab6cd9946b798c187c2a9350852",
  "pdfa": {
    "standard": "PDF/A-3b",
    "conformant": false,
    "validator": "veraPDF 1.30.2",
    "id": "90614253-7e8d-4f90-b1a2-3d4e5f607182",
    "versions": { "verapdf": "1.30.2", "pdfbox": "3.0.8" },
    "pdf_sha256": null,
    "messages": [
      {
        "severity": "error",
        "rule": "6.2.11.4.1-1",
        "message": "…",
        "location": "…"
      }
    ]
  },
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

An e-invoice carries the same finding inside einvoice:

{
  "type": "https://docs.formfeed.dev/errors/pdfa-validation-failed",
  "title": "PDF/A validation failed",
  "status": 422,
  "detail": "The PDF could not be made a valid PDF/A-3b: 1 finding",
  "code": "pdfa_validation_failed",
  "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": "PDF/A-3b",
      "messages": [
        {
          "part": "pdf",
          "severity": "error",
          "rule": "6.2.11.4.1-1",
          "message": "…",
          "location": "…"
        }
      ]
    },
    "display": null
  },
  "request_id": "req_4b7c1e9a2f3d4c5b8a6e7f9012"
}

Common causes​

  • A font that is not embedded (6.2.11.4.1-1). PDF/A needs every font inside the file. A PDF of the file library that is appended with post.merge_after can bring such a font.
  • A font whose embedded program disagrees with the widths the PDF states (6.2.11.5-1). The office converter writes such a font for OpenType fonts with CFF outlines, which on our side is the font for Chinese, Japanese and Korean text in a Word or PowerPoint template.
  • With "pdfa": "2b": a file attached to the document that is not itself PDF/A (6.8-5). PDF/A-2 takes no other attachment; PDF/A-3 takes any.

How to fix it​

  • Read pdfa.messages, or einvoice.validation.messages for an e-invoice, to see which clause of PDF/A the file breaks, and where. What fails and why explains each rule.
  • For a font that is not embedded in an appended PDF: create that PDF again with its fonts embedded, or leave it out of the PDF/A.
  • For Chinese, Japanese or Korean text in a Word or PowerPoint template: render it from an HTML template.
  • For an attachment at "2b": ask for "3b".
  • For anything else, send the render_id to support@formfeed.dev. A document that Formfeed rendered and cannot convert is ours to fix.

Retry?​

No. The same document fails the same way, and async renders are not retried for this code either. Change what the report names and send the request with a new Idempotency-Key or none: as with every 4xx, the old key returns this answer again for 24 hours.