From Technical Translation to Equivalent Meaning
Financial documents travel between organizations, networks, and systems that don’t always “speak” the same language. An order might come from an ERP system as an EDI message, a supplier might send an invoice in UBL, another system might expect its own XML structure, and an older application might only be able to process a fixed CSV file.
In addition, financial documents arrive as PDFs, scans, or images. These sources are digital, but that doesn’t mean they’re structured or immediately machine-readable. Before they can be converted to another format, text, tables, and relevant data must first be recognized and given meaning.
Conversion makes such a document suitable for the receiving system. This involves more than just the file format. The content must retain the same meaning. An invoice number must remain an invoice number in the target format, a discount must not be interpreted as a surcharge, and an order reference must be placed at the correct level.
This distinction is defined in standards for electronic invoicing. EN 16931 describes a semantic model that defines the meaning of invoice data and business rules. That meaning can then be linked to various technical syntaxes. UBL also contains reusable data components and schemas for orders, shipping notices, and invoices, among other things. Conversion is thus essentially a semantic translation with a technical output format.
Where Traditional Automation Falls Short
Traditional conversion relies on predefined mappings: field A from the source format becomes field B in the target format, possibly supplemented with transformations and decision rules. For stable, structured messages, this approach is accurate, verifiable, and efficient.
Complexity arises from variation. Organizations use different standards, versions, and country- or industry-specific profiles. On top of that come proprietary extensions, codes, and interpretations. Even parties that formally use the same format may populate information differently or use optional fields in different ways.
As a result, a single conversion quickly turns into a collection of exception rules. A new supplier format, a changed field name, or a different placement of a reference requires a customized mapping. The number of possible connections increases further when each source format is translated directly to each target format.
Technical validation only addresses a portion of these issues. An XML schema can verify whether elements, data types, and structures are valid. Additional business rules can, for example, validate required data, calculations, and code lists. However, a message can be technically valid while a source field is incorrectly mapped in terms of content. Syntactic validity does not necessarily imply semantic correctness.
OCR recognizes text, but not always its meaning
For PDFs, scans, and other less structured sources, processing often begins with Optical Character Recognition (OCR). OCR converts characters in an image into machine-readable text. Traditional document processing typically goes a step further by using fixed templates, recognition zones, anchor words, and rules. A value to the right of the “invoice number” label can thus be linked to a predefined field.
This approach works well as long as documents have a predictable layout. The error rate increases when suppliers use different templates, shift fields, have tables that span multiple pages, or label the same information differently. The quality of the source image also affects character recognition.
Furthermore, error-free text recognition is not the same as understanding the content. The value “14-05-2026” may have been read correctly, but it still needs to be determined whether it refers to the invoice date, due date, or delivery date. An amount could be a line item amount, a VAT amount, or the invoice total. Therefore, conversion requires not only recognizing what is written but also understanding what the information in the document means.
How Intelligent Automation Can Help
Intelligent automation can be particularly helpful with the aspects that cannot be effectively described using fixed mappings. It can combine characteristics from field names, values, document structure, and surrounding context to identify potential correspondences between source and target fields. Research on schema matching focuses precisely on this problem: finding semantic relationships between different data structures.
Intelligent Document Processing as a Gateway
For PDFs, scans, and images, the term Intelligent Document Processing (IDP)is often usedin this context . IDP is not a standalone AI technique, but a collective term for document processing that combines OCR with, among other things:
- document type classification;
- recognition of layout, tables, and the relationship between labels and values;
- extraction of fields and lines;
- normalization to agreed-upon data types and values;
- validation and processing based on confidence levels and business rules.
This distinction from traditional OCR is therefore functional. OCR makes text machine-readable. IDP attempts to turn that text and the visual document structure into usable, structured data. The result, for example, is not just the recognized text “May 31, 2026,” but a value identified as an expiration date and delivered in an agreed-upon date format.
IDP is not automatically the same as generative AI, however. Document classification, image recognition, layout analysis, machine learning, and fixed rules can all be part of the same processing. The term primarily refers to the goal: converting unstructured or semi-structured documents into reliable process data.
For machine-readable XML, UBL, and EDI messages, OCR or IDP is usually not necessary. In those cases, data must be parsed directly and processed via controlled mappings. Intelligent document processing primarily serves as the gateway for sources whose structure is not explicit enough.
The result does not necessarily have to be an automatic conversion. The processing can first determine the document type, the variant used, and probable field relationships. For existing mappings, it can identify discrepancies and propose an appropriate mapping. Uncertain or new relationships can be submitted for review, while known variants are processed according to an approved mapping.
A robust approach uses a canonical data model as an intermediate layer. Source formats are first translated into a single internal semantic model and from there into the desired target format. Intelligent interpretation helps link the source to that model; fixed transformations then generate the target message.
Afterward, fixed, reproducible checks remain paramount. The result must comply with the target schema, applicable business rules, code lists, and arithmetic relationships. Amounts, VAT logic, and mandatory references must not be filled in simply because a value seems plausible. Furthermore, the original source, the mapping applied, and any derived interpretations must remain separately traceable.
OCR, IDP, and format conversion thus constitute sequential steps, though not all are always necessary. OCR reads text from an image source. IDP structures and interprets less predictable documents. Fixed mappings translate the established meaning into a canonical model or target format. Schemas and business rules then verify whether the result may be processed.
Intelligent automation does not, therefore, replace the standard. It helps accommodate variation before the standard is applied:
Let intelligent automation recognize the meaning where the source varies, and let fixed mappings and validation rules determine what the target format accepts.