OCR Bilingual Contract Scans: Two Languages Side by Side
By Schema LawPublished Updated
To OCR a bilingual contract without mixing the two texts, find out how the languages are laid out, give the software one language at a time where you can, and rebuild the result as a table with one row per clause and one column per language. Then read every number and date in both columns against the scan.
How are bilingual contracts laid out on the page?
A bilingual contract puts its two language versions on the page in one of three ways: parallel columns, facing pages, or alternating paragraphs. Look at three or four pages from the middle of the scan to see which one you have, because the layout decides how you convert it.
| Layout | What the scan looks like | What goes wrong in conversion |
|---|---|---|
| Parallel columns | Each page is split down the middle, one language on each side, clause 1 beside clause 1 | Lines from the two sides are joined into one |
| Facing pages | Left-hand pages in one language, right-hand pages in the other | Little on the page itself, but the text comes out as alternating pages |
| Alternating paragraphs | Each clause appears in one language, then straight after in the other, perhaps in italics | The text is in the right order but nothing marks where one language stops |
Some contracts mix these. The body runs in two columns, a schedule of prices appears once with bilingual headings, and the signature page is in one language only. Note where the layout changes before you start, page by page, so you know which pages need which treatment.
Also check whether the scan is a contract at all in both halves. A translation attached behind a single-language agreement is a different thing from a contract signed in two languages, and the signature pages will show you which you hold.
Read the commercial terms in both columns of a distribution agreement before you build the pair table. Look for an arbitration agreement and any sentence about negotiation of disputes, and write the clause number from each language. Then check that the party names, the dates, and the price figures agree on the signature page.
Why does OCR interleave the two languages of a bilingual contract?
OCR interleaves the two languages when it reads straight across a two-column page, treating the left column and the right column as one wide line. The English half of a line is followed by the other language's half, and every sentence is cut in two.
The cause is reading order, not language. The software has to decide where a column ends, and a narrow gutter or a skewed page can hide the gap. The post on whether OCR can handle two-column documents explains how that decision is made and how to repair it.
Language adds a second problem. Recognition set up for one language can strip accents or guess wrong letters in the other, which is covered under why the recognition language setting matters. On a bilingual page, both problems can show up together, so judge the output of each column separately.
Interleaving is easy to spot. Open the converted text and read the first numbered clause. If a line starts in one language and finishes in the other, the columns were merged.
Converting a two-column bilingual contract into paired clauses
Convert a two-column bilingual contract by getting each language out as its own run of text, then pairing the two runs clause by clause in a table. The clause number is the key that joins them. The finished table has one row per clause and reads across, like the paper.
- Keep the scan. Work on copies. The signed scan stays as it arrived.
- Test one page as it is. Run a middle page through your OCR tool and read the result. If each column came out whole, one after the other, you can convert the full file directly. With Schema Law, the Free plan's three pages per document are enough for this test, and you see the result page by page on screen, so you can check it against the original.
- If the columns merged, split the page images. In a PDF editor or image editor, crop each page into a left half and a right half and save two files: every left half in page order, every right half in page order. Each file now holds one language in one column.
- Convert each file. Where your tool has a language setting, set it for the language of that file.
- Break each text into clauses. Start a new block at every clause number. Sub-clauses can stay inside their parent unless you need them separately.
- Build the pair table. Paste the two texts into a spreadsheet or a Word table: clause number, first language, second language, scan page.
- Check the joins. Every row must have text in both language cells. An empty cell means a clause number was misread or one version has a clause the other lacks.
For a facing-page contract, skip step 3 and instead pull the odd pages into one file and the even pages into another. For alternating paragraphs, convert the scan whole and split the text by hand at each change of language.
A clause-pair table
Suppose Halvard Marine Supply Ltd and Distribuidora Ostrea, S.A. de C.V. signed a distribution agreement in English and Spanish. Both companies are invented. The table begins:
| Clause | English | Spanish | Scan page | Checked |
|---|---|---|---|---|
| 1.1 | "Territory" means the states listed in Schedule A. | Text of clause 1.1 from the right column | 2 | Yes |
| 4.2 | Distributor shall pay each invoice within 45 days. | Text of clause 4.2 from the right column | 5 | Yes |
| 18.3 | Text of the governing language clause | Text of clause 18.3 from the right column | 14 | Yes |
The scan page column lets anyone go from a row to the image. The checked column records that a person compared the row with the page, not that software did.
A table like this is a working copy. It is not a translation and it is not the contract. If you need to line up two full texts and see where they differ, the method in how to compare two scanned contracts applies to two versions in the same language; across languages, the pair table and a reader of both languages do that job.
Where does a bilingual contract say which language prevails?
Look for a clause that names one language version as controlling if the two differ. It is commonly called a governing language or prevailing language clause. Search the whole text for it, because nothing fixes where it sits. A bilingual contract may have no such clause, so an empty search is a finding to report.
Search the English text for "prevail", "language", "translation", "version", "discrepancy" and "inconsistency". Read each hit, because "language" also appears in phrases such as "the language of this clause". When you find the clause, note its number and go to the same number in the other column.
Then record both texts of that clause in the pair table and have someone who reads both languages compare them. This is the one clause where a difference between the versions matters before any other. If the English column says English controls and the other column says the other language controls, the contract disagrees with itself, and that goes to the responsible lawyer at once.
What the clause achieves is a legal question that depends on the governing law and on any local rule about the language of contracts. This post covers finding and recording the clause. Check your own jurisdiction for its effect.
Three things to write down:
- the clause number and scan page in each language;
- the exact wording in each language, proofread against the image;
- whether schedules, exhibits and later amendments are in both languages or one.
Checking that both language versions carry the same numbers and dates
Check numbers and dates by pulling every figure out of each language column and comparing the two lists row by row. Figures are the part of a bilingual contract you can verify without reading both languages, and a wrong digit in either column changes a price, a deadline or a cross-reference.
Add two columns to the pair table, one per language, and list every figure the clause contains: amounts, percentages, day counts, dates, and cross-references to other clauses. Then compare.
| What to compare | What a mismatch can mean |
|---|---|
| Amounts and currency codes | A misread digit, or a real difference between the versions |
| Decimal and thousands marks | The two languages may write 1,500.00 and 1.500,00 for one amount; confirm which convention each column uses |
| Dates | Day and month order can differ between the columns, so 03/04/2025 may not be the same day on both sides |
| Periods in days or months | A number written in words in one column and digits in the other |
| Clause cross-references | One version was renumbered and the other was not |
When two figures differ, open the scan before you conclude anything. If the page images agree and the converted texts do not, it is a recognition error; correct the table. If the page images themselves differ, the contract has a discrepancy. Do not fix it. Record both figures, the clause number and the scan pages, and pass it on with the prevailing-language clause beside it.
Dates and figures are also the entries to read slowly in any single-language contract; the post on why OCR gets numbers wrong lists the digit swaps to expect. For the formats you can export a converted column in, including Word and Excel, see the export formats on the Schema Law homepage.