Keldmoor, a fictional industrial distributor from Ohio, buys fasteners in Milwaukee, plastic housings in Monterrey and tooling in Turnov, in the Czech Republic. So its invoices arrive as INVOICE, FACTURA and FAKTURA. One supplier prints the date as 09/11/2026, another as 2026-09-17, the third as 15. 9. 2026. One writes the total as 13,800.00, another as 3 960,00. The accounts payable team needs all of them in one invoice book, in one format, before it can plan a single payment.
Our new video, Document → data → action, follows those September invoices through DocReveal — from PDFs in three languages, through one shared structure, to a finished row in the invoice book. It runs three and a half minutes, you can watch it at the top of this page, and it is made for finance, accounts payable and operations teams. Here is what you will see, and why it matters.
The hidden cost of buying abroad
International suppliers are good for prices and resilience. They are less good for the back office. Every new supplier brings a new layout, and every new country brings a new language, new date and number conventions and sometimes a new currency.
The usual answers are retyping, or a template per supplier that breaks the day the supplier changes its layout. Both grow with the number of suppliers, not with the value of the work.
Read: every invoice, in any language
The video opens in Reveal Manager. One run processes six September invoices — four in English, one in Spanish and one in Czech — against one invoice model, with live progress for every file. There is no template for any of them.
Each file is recognised as what it is: the Spanish factura and the Czech faktura are both typed as invoices, just like the four English ones. All six are mapped into the same model and written to the same analytics dataset.
Recognise: your names for your documents
How does DocReveal know that a factura is an invoice? It reads the document’s own heading, in whatever language it is written, and translates it into one document type. In Model Manager, the team sees the document types found in its documents so far: invoices, purchase orders, contracts, receiving reports.
The team stays in control of that vocabulary. It can add aliases in any language, such as Factura and Faktura for invoices, confirm types the system has proposed and merge duplicates. The classifier learns from confirmed documents, and corrections apply to documents processed from then on.
Structure: one model, the same fields
Recognising the type is half of the job. The other half is the structure. The invoice model defines the fields once — document number, issue and due dates, currency, total amount, supplier, line items and language — and every invoice is mapped into it, whatever its layout.
The formats become one format, too. 09/11/2026, 2026-09-17 and 15. 9. 2026 all become ISO dates. 13,800.00 and 3 960,00 become plain numbers with the currency next to them. The Spanish invoice’s “30 días (vence 2026-10-17)” becomes a due date. From here on, an invoice is an invoice, whoever wrote it and in whatever language.
These are the same September invoices you may know from Checked, not trusted and Ask your invoices. There the question was whether they add up and what they add up to. Here the question is where their data goes next.
Deliver: a row in the invoice book
Clean data only pays off once it reaches the tools people work in. In Integration Manager, the video builds a flow in a few steps: it starts when a document has been processed, continues only for invoices and adds a row to the team’s invoice book in a spreadsheet. The columns are mapped to invoice fields — supplier, invoice number, due date, currency and total — not to positions on a page.
One click publishes the flow and switches it on. From then on, every processed invoice leaves a record in the activity log, with the input and output of each step. And the invoice book fills up: six rows in one format, whether the invoice came from Milwaukee, Monterrey or Turnov. The same data can just as well go to an accounting system, a CRM or a team chat.
What to take away
- Stop building a template per supplier. A system that reads meaning rather than positions on a page keeps working when a layout changes.
- Agree on one structure first. Define the fields your business needs once and map every document into them; every report, check and flow then builds on the same data.
- Teach the system your vocabulary. Your document types and aliases, confirmed by your team, keep recognition stable.
- Automate the delivery, keep the record. Let processed documents flow into your tools, and keep every run on record.
All companies and figures in the video are fictional demo data.
One structure. Every language.