I’m leaning on ABBYY FineReader 16 and Excel Power Query to clean and normalize bank statements before Bates stamping and Rule 1006 summaries; on a recent matter we ran about 12,000 pages of JPM PDFs and cut reconciliation time in half by catching OCR’d minus signs and merged columns up front. For those prepping expert reports and depo binders, are you validating balances in IDEA/ACL or building checks into Relativity processing — what’s your workflow for catching OCR drift before it becomes an exhibit error?
I add a ‘running balance delta’ column; catches breaks; Tabula helps ugly tables (https://tabula.technology/). Watch locale decimals.
helps ugly tables (https://tabula.technology/); watch locale decimals. I’ve had better luck exporting FineReader as plain text (not tables), then in Power Query replace U+2212 and U+00A0 before Number.From with culture ‘en-US’ — that stopped the sneaky negative/merge issues on JPM; small caveat: ABBYY’s table mode kept misreading thousands separators.
Short answer from my side: I’m seeing the same pattern — one concrete thing that helped was writing down the exact handoff and timebox it to 15–20 min. Does that match what you’re running into?
After FineReader 16, I reconcile per page: opening + net = closing; catches OCR-minus issues before Bates — thanks @ashton_77r.
I build a composite key in Power Query (date + amount + trimmed description/check #) for an “overlap dedupe” because JPM repeats the last few days on the next statement — like catching photocopied pages sneaking in twice. Caveat: same-day same-amount items can be legit, so include a few chars of the trans ID or check number in the key. Do you see those repeats on your 12k set?