Do you translate the document first?

No. Translation before extraction throws away the layout and the field positions that extraction depends on, and it introduces a second place for meaning to change. Languages are tagged and the document is read as it is, in the script it was written in.

What happens with two languages on one page?

Both are tagged and both are read into the same record. Three in four invoices in this flow carry more than one language, so a mixed-script page is handled as the ordinary case rather than routed out as an exception.

How do you handle a currency the document does not name explicitly?

Currency is inferred from the document — symbols, tax wording and registration details all carry the signal — rather than assumed from the vendor's registered country, which is frequently not the country the invoice was raised in. Where inference is not safe, the field is raised for review.

What if the tax rate on the document does not match the amounts?

The rate is derived from the values and compared against the rate printed on the page. A disagreement becomes an exception carrying both figures. Silently preferring one over the other would produce a clean-looking record that nobody could defend at an audit.

Does adding a new country mean new development?

Adding a market means configuring its rules: the registration format, the tax treatment and the currency handling. Extraction runs against those processing rules rather than against a template per vendor, so the vendor list can grow without the maintenance burden growing with it.

Where do the finished records go?

Into the systems that already consume them, in one canonical structure regardless of the language the invoice arrived in. Each record keeps the document, the languages detected, the type it was classified as and the exceptions raised along the way.

← All solutions

Solutions

One canonical invoice record, whatever language it arrived in

Invoices from vendors across several countries and tax regimes, in English and Arabic and a long tail of other languages — frequently two scripts on the same page — tagged, classified and extracted against your processing rules rather than a template per vendor.

Book a demo

Mixed-script pagesFive canonical document typesTax rates derived and cross-checked

Languages read natively

Including right-to-left script, without a translation step between reading and extraction.

3 in 4

Invoices in more than one language

Mixed-script pages are the normal case in this flow rather than the exception to handle later.

Currencies handled in one flow

Currency is inferred from the document and amounts are standardised on the way in.

Payables

ManufacturingLogisticsOCR & extractionMulti-lingualERP write-backAudit trail

The challenge

A cross-border e-commerce marketplace receives invoices from vendors across several countries and tax regimes. They arrive in English and Arabic and a long tail of other languages, and three in four carry more than one language — frequently two scripts on the same page, with the vendor's details in one and the tax detail in the other. Layouts, currencies, VAT treatment and registration formats all differ by market. A template per vendor does not scale across that spread, and a translation step before extraction loses exactly the structure extraction depends on. The practical consequence was that a shared service centre worked from documents rather than from data, and every market had its own way of being read.

What we built

A pipeline that collects invoices off a secure drop on a schedule, tags the languages present on each document including mixed-script pages, and classifies every document into one of five canonical types before any extraction begins. Only then is the full field set extracted, against the customer's own processing rules rather than a generic per-vendor template. Currency is inferred from the document, amounts are standardised, and tax rates are derived from the values and cross-checked against the rate printed on the page. Every default applied and every exception raised is logged with the document it came from, so a reviewer sees what the pipeline decided as well as what it read.

The result

A shared service centre works from one structure instead of one per market. An invoice in Arabic, an invoice in English and an invoice carrying both produce the same record, with the same fields, in the same currency convention. Because classification runs before extraction, a credit note is never read as an invoice and quietly netted the wrong way. Where the derived tax rate disagrees with the rate printed on the document, the pair is raised as an exception rather than resolved silently in favour of either. Ten currencies and several registration formats are handled inside one flow, with the market-specific rules held as configuration.

Process

How it works

Four stages. Language and document type are settled before any field is read, because what a value means depends on what kind of document it is sitting on.

01
Ingest
Invoices are collected from a secure drop on a schedule, across markets, with each batch tracked from the file that arrived to the record it produced. Nothing is pulled from a mailbox a person also works in, so what the pipeline processed and what a reviewer saw are never in question.
02
Detect & classify
The languages present on each document are tagged, including pages carrying two scripts at once, and the document is classified into one of five canonical types. Classification comes before extraction because the same number means different things on an invoice, a credit note and a statement.
03
Extract
The full field set is read against the customer's own processing rules rather than a template maintained per vendor. Layout differences between markets are absorbed by those rules, so onboarding a new supplier is not a development task and a supplier who redesigns their invoice does not break the flow.
04
Validate & export
Currency is inferred and amounts standardised. Tax rates are derived from the values on the document and cross-checked against the rate printed on it, and a disagreement is raised rather than resolved silently. Every default and every exception is logged before the canonical record is exported.

What it does

Inside the solution

Mixed-script pages read as one document

Two languages on the same page is the normal case here, not an error state. Both are tagged and both are read, so a document with the supplier block in one script and the tax block in another produces one complete record.

Classification before extraction

Each document is placed into one of five canonical types before any field is read. An amount on a credit note is not an amount on an invoice, and deciding that afterwards is how a payables ledger acquires the wrong sign.

Extraction against your processing rules

Fields are read against the customer's own rules rather than a template per vendor. A long tail of suppliers across several markets is the reason: maintaining a template each is work that grows with the vendor list and never ends.

Currency inference and standardisation

The currency is inferred from the document rather than assumed from the vendor's country, and amounts are standardised on the way in, so downstream comparison is between values rather than between conventions.

Tax derived and cross-checked

Rates are derived from the values on the document and compared against the rate printed on it. Where the two disagree the exception is raised with both figures, because one of them is wrong and the pipeline is not the right place to decide which.

Registration formats by market

Tax registration numbers differ in structure by country. Each is validated against the format of the market it belongs to, so a malformed number is caught at capture instead of at filing.

Defaults and exceptions logged

Where the pipeline applies a default it says so, and where it cannot it raises an exception. A reviewer sees what was decided as well as what was read, which is what makes the record defensible months later.

Scheduled collection and export

Documents are collected from a secure drop on a schedule and the canonical records are exported into the systems that consume them, with each batch traceable from the file that arrived to the record it produced.

Foundations

The VapusFin models behind it

Document Intelligence

Read leases, contracts, KYC files, loan forms, invoices, statements and transaction data, work out what each one means in context, apply the rules that govern it, reconcile it against the system of record and complete the work it was always going to trigger.

Details

Accounts Payable Automation

Accounts Payable

Capture every invoice however it arrives, match it line by line against the PO and the goods receipt, and pay only what the contract says you owe.

Details

Tax & Compliance

Tax & compliance

Indirect tax — VAT, GST or sales tax — derived and checked against the document, withholding tax determined per counterparty and payment type, and statutory registers prepared in the format the local regime asks for.

Details

Questions

Frequently asked

Do you translate the document first?: No. Translation before extraction throws away the layout and the field positions that extraction depends on, and it introduces a second place for meaning to change. Languages are tagged and the document is read as it is, in the script it was written in.
What happens with two languages on one page?: Both are tagged and both are read into the same record. Three in four invoices in this flow carry more than one language, so a mixed-script page is handled as the ordinary case rather than routed out as an exception.
How do you handle a currency the document does not name explicitly?: Currency is inferred from the document — symbols, tax wording and registration details all carry the signal — rather than assumed from the vendor's registered country, which is frequently not the country the invoice was raised in. Where inference is not safe, the field is raised for review.
What if the tax rate on the document does not match the amounts?: The rate is derived from the values and compared against the rate printed on the page. A disagreement becomes an exception carrying both figures. Silently preferring one over the other would produce a clean-looking record that nobody could defend at an audit.
Does adding a new country mean new development?: Adding a market means configuring its rules: the registration format, the tax treatment and the currency handling. Extraction runs against those processing rules rather than against a template per vendor, so the vendor list can grow without the maintenance burden growing with it.
Where do the finished records go?: Into the systems that already consume them, in one canonical structure regardless of the language the invoice arrived in. Each record keeps the document, the languages detected, the type it was classified as and the exceptions raised along the way.

Want the same outcome?

Send us a sample across your markets — mixed-script pages included — and we will show you the classification, the extracted fields and the tax exceptions before you commit to anything.

Book a demo

Last reviewed 4 September 2026

One canonical invoice record, whatever language it arrived in

The challenge

What we built

The result

How it works

Ingest

Detect & classify

Extract

Validate & export