Skip to content
OCR-AI
Open a document
All articles

Getting document data into other systems: Excel, CSV and JSON

You have the data from a document. Now it has to reach your accounting software, your CRM or a sheet. What each format is good for, and where Hebrew trips it up.

Published September 25, 2025Updated October 25, 20263 min read

You have extracted data from a document: supplier, date, amounts, a table of lines. Now it has to reach the place where it is used: a sheet, accounting software, a CRM or an internal system. Each destination suits a different format, and with Hebrew each format has its own trap.

Which format for which destination

FormatGood forNot good for
ExcelPeople: checking, filtering, calculatingAutomatic import into a system
CSVSystems that import a fileA document with several different tables
JSONDevelopers and systems: the whole structure, positions includedReading by eye
Plain textSearch, archives, pasting into a documentData you need to calculate with

Excel

The workbook holds a fields sheet, a sheet for each table and a sheet for the full text. For a Hebrew document, the sheets open right-to-left. Dates are stored as real dates, so you can sort and filter by them, and amounts as numbers, so formulas work without conversion. The fields sheet has a column marking which values needed review.

CSV

CSV is the format most systems can import, and also where Hebrew breaks most often:

  • Encoding. A Hebrew CSV that opens in Excel as gibberish was saved without the marker that identifies it as UTF-8. Our files include that marker (a BOM), so they open in Hebrew.
  • Formulas. A cell starting with = or + may run as a formula when the file is opened in a spreadsheet. In our files such a cell gets a leading apostrophe and stays text.
  • Commas inside values. An address like "5 Herzl St, Tel Aviv" is wrapped in quotes, so it stays in one cell.

The fields CSV includes a fixed key for each field (such as vendor_tax_id or total), the field name, the value as written, the normalised value, and the review mark. In the target system, map by the key rather than the name, because the key does not change between languages.

JSON

The JSON file holds the whole result, page by page:

KeyWhat it holds
document_typeThe document type, such as invoice
languageThe document's language
summaryA one-sentence summary
fieldsThe fields: key, name, value, normalised value, type, position on the page, review mark
tablesThe tables: title, columns and rows
textThe full text

The normalised values are the most useful part for systems: dates as YYYY-MM-DD, and amounts as plain decimals without a currency sign or thousands separators. That way "05/03/2026" is not read as May 3rd, and "1,234.50" does not fail an import.

Where Hebrew trips things up

  • Dates. 05/03 is March 5th in Israel and May 3rd in the US. Use the normalised value.
  • Amounts. The shekel sign, thousands separators and a minus on the wrong side break imports. Again, the normalised value solves it.
  • Text direction. Pasting Hebrew text with numbers into a system without bidirectional support can reverse the order. Check the result in the target system.

And an API?

There is no public API yet. Today the data leaves as files, and for most processes that is enough. If you need a direct, high-volume connection, write to us and tell us what you need.

More from the blog