Solutions
Figures and tables, not data interchange.
Financial documents are tables with prose around them, and the tables are the part that has to be exactly right. We handle the documents — not EDI or structured data interchange, which is a different problem entirely.
What makes these documents hard
Four document-level failures with real consequences.
A figure that changes
A number altered in processing is the worst failure in this document class. It is also invisible to a text-level review that is reading for fluency.
Tables that break
Financial tables are dense, aligned and unforgiving. A table that loses its column alignment is no longer readable as a table.
Currency and format conventions
Decimal separators, thousands separators, date formats and currency notation differ by market and have to be handled deliberately rather than left to chance.
Scanned statements
Older statements and filings arrive as scans, sometimes interleaved with digital pages in the same file.
The documents we get
The document types that come up most in this category.
Annual and interim reports
Long documents, heavy on tables and figures, laid out to a template.
Financial statements
Dense tables where column alignment and figure accuracy are the entire point.
Regulatory filings and disclosures
Template-driven, with formatting conventions that are part of the requirement.
Investor and client communications
Presentations and letters, where layout carries the message.
Terminology and consistency
Figures are checked visually, against the source.
The pipeline's visual check compares the rendered output against the source document. For financial material this is the check that matters: a number that changed during processing, a decimal that moved, a row that shifted out of alignment.
Terminology for financial instruments, entity names and product names comes from your term list — up to 2000 terms, applied during translation.
One thing to be explicit about: EDI and structured data interchange are not what we do. If your requirement is a data format rather than a document, we are the wrong tool and we would rather say so now.
How the work runs
Four steps, same pipeline for every industry.
- 01
You send one real document
The awkward one if you have it. It is evaluated on the same path your production work would take.
- 02
We run it end to end
Inspection, per-page routing, translation with your terminology applied, independent review, visual verification.
- 03
You judge the returned file
Layout, terminology, the pages that normally break. That is the evaluation.
- 04
Scope is agreed separately
Volume, language pairs, turnaround and integration. The sample tells you whether to have that conversation at all.
Questions
Do you handle EDI or structured data interchange?
No. EDI is a data format problem, not a document problem, and it needs different tooling. What we handle is financial documents — PDF, Office formats and images.
How are figures protected?
The rendered output is compared against the source before delivery, which is how a changed number or a shifted row is caught.
Do you handle currency and decimal conventions?
Market conventions are part of the translation rather than an afterthought. If your output has specific requirements, tell us at scoping.
Can you enforce entity and product names?
Yes — your term list, up to 2000 terms, applied during translation.
Are you able to sign off on regulatory filings?
No. We produce the translated document. Regulatory acceptability and sign-off are your reviewers' responsibility.
Send us a document with a dense table in it.
Figure accuracy and column alignment are the two things worth testing, and one real file tests both.
- No signup, no self-service portal — you send a file, we run it.
- You get the finished document back, not a screenshot of one.
- If it is not good enough, you have lost nothing.