PDF/A validation

The PDF/A validation is carried out by the Pdfa web service.

HTTP REST-API	OpenAPI
POST /pdfa/{documentId}	🔗

This is a special function of the web service for PDF/A conversion. In this case, the web service does not directly carry out a conversion, but checks an already existing PDF/A document against a specific PDF/A standard (validation).

This mode can be enabled with the analyze option in the web service parameters.

In order to run a validation, the "Pdfa" web service needs to be run with the analyze parameter. In addition, the level parameter must be used to define the PDF/A standard that will be used to check the PDF document. If a PDF/A document is provided at the time the web service is called, then it will be checked against the defined standard (validated).

{
  "pdfa": {
    "analyze": {
      "level": "1a"
    }
  }
}

In a PDF/A check, only the first step of the PDF/A conversion is carried out: The analysis of the PDF document.

There must be no errors already as of this step for a PDF/A document to comply with the selected standard. The PDF/A check does not carry out a conversion of the PDF document (to eliminate errors).

Once the check has been carried out, the web service returns an XML report as the result.

If the check is successful, i.e. a PDF document complies with the required PDF/A standard, then the error in the XML report is set to 0.

<result>  
   <error>0</error>  
   <sub-error>0</sub-error>  
</result>

If the check is unsuccessful, then the XML report contains the corresponding error code. In this case, the other sections in the report will contain more detailed information concerning the reason why the check was unsuccessful (please refer to XML report for details)

PDF/A check in the portal

It is also possible to carry out a check of a PDF/A document in the Web Portal.

If this is done in the web portal and the check is successful, a message to this effect will appear.

If the operation is not successful, an XML report is also returned (see PDF/A Conversion) which contains information about the errors.

In order to provide additional information in the event of errors, the web portal makes it possible to download an XML error report. To see the complete report, click on the download button (see the image).

This report will also be available if you call the "Pdfa" web service directly from a programming language or from an application of your own, for example. Within this context, the errorReport and successReport parameters are used to control when and how this report will be returned (please refer to PDF/A conversion)

Invoice rule validation

Since webPDF 10.0.7, PDF/A validation can additionally check a ZUGFeRD, Factur-X, or XRechnung invoice that is already embedded in the uploaded PDF/A document against an official e-invoicing business rule package, using the same invoiceRuleValidation parameter described for PDF/A conversion:

{
  "pdfa": {
    "analyze": {
      "level": "3b",
      "invoiceRuleValidation": {
        "mode": "report"
      }
    }
  }
}

This mode does not require the document to already carry a rule-validation-friendly structure beyond a normally embedded invoice: webPDF looks for the invoice attachment among the document's embedded files, the same way a ZUGFeRD/Factur-X/XRechnung reader would — first by an XMP DocumentFileName pointer, then by one of the canonical invoice file names (factur-x.xml, zugferd-invoice.xml, ZUGFeRD-invoice.xml, xrechnung.xml), then by the PDF/A-3 AFRelationship marker. Only the document-level embedded files are considered, not file attachment annotations on individual pages.

Unlike PDF/A conversion, this check runs against an arbitrary uploaded PDF document rather than one webPDF itself just embedded the invoice into, so it also has to account for cases that cannot occur on the convert side — no matching attachment, more than one equally likely candidate, or an attachment that is too large or cannot be decoded safely. These are reported as additional notEvaluable reasons on the invoice element of the XML report:

Reason	Meaning
noInvoiceAttachment	No embedded file qualified as the invoice.
ambiguousInvoiceAttachment	More than one embedded file qualified equally; none of them is used.
tooManyAttachments	The document has more embedded file entries than maxAttachmentCandidates allows (see server-wide settings); it is rejected rather than silently only considering the first ones.
invoiceAttachmentTooLarge	The chosen attachment's raw (still compressed) size exceeds maxAttachmentCompressedSize, checked before it is decompressed.
invoiceAttachmentUnreadable	The chosen attachment could not be decoded safely (an unsupported compression filter, for example) or is not well-formed XML.
sourceDocumentUnreadable	The uploaded PDF document itself could not be opened, for example because it is encrypted and no matching password was provided.

The result of the check itself — a state of compliant, nonCompliant, or notEvaluable with one of the reasons above or one of the reasons shared with PDF/A conversion — and, under mode: "enforce", the enforcement outcome, are always part of the analysis report: since analyze never embeds anything, the report is always the operation's response, unlike PDF/A conversion where a report is only returned when errorReport/successReport request one.

note

Invoice rule validation never changes the PDF/A result/error in the report — that value keeps describing only the PDF/A conformance check. A rejected invoice under mode: "enforce" is visible exclusively through the invoice element's enforcement attribute, so a caller evaluating the enforcement decision needs to read that element, not just result/error.

Since webPDF 10.0.7, originalReport and originalReportHtml also work in this branch, on the invoice extracted from the uploaded document, and the report's invoice element carries timestamp, validationStep and document the same way — see Original rule-package report for details.

Invoice XML without a PDF

To check an invoice XML that is not embedded in a PDF, use the invoice operation of the same web service instead of analyze — see Invoice validation without a PDF. An invoice XML sent to analyze is treated as a PDF/A validation of an unreadable PDF.