agent's PDF statement parser returned an empty balance column and every ma

Not specified by the original author.

TL;DR

An empty balance column usually means the PDF has no text layer for those cells, because the statement is a scanned image, or the balances are rendered with a font the extractor maps to blanks. Check whether the PDF has selectable text; if not, run OCR on the pages. Then locate balances by their pattern, a currency amount at a consistent position or following a label, rather than assuming a fixed column index that the layout may shift per page.

agent's PDF statement parser returned an empty balance column and every match failed

Use this when

• The parsed output shows balances as empty while other columns extract.
• The PDF pages look like scans or the text cannot be selected in a viewer.
• Matches fail because every expected balance is missing, not because amounts disagree.

Not for this skill when

• The PDF is password protected or corrupt. Obtain an accessible copy from the bank first.
• Balances extract but are wrong values, such as picking up a neighbouring column. That is an extraction targeting problem, narrower than this one.

Steps

1. Open the PDF and test text selection on the balance area, and check the document properties for a text layer or image-only pages. Verify: you know whether the page is text or image
2. If image-only, run OCR on the statement pages and compare OCR text against the visible balances on one page. Verify: OCR output contains the balance values a human reads
3. Identify the balance pattern: its position, its format, or the label it follows, across several pages. Verify: the pattern holds on pages with different row counts
4. Retarget the parser to the pattern and re-extract, checking that every row now has a balance. Verify: no balance cell is empty in the new extraction
5. Tie the extracted closing balance and a sample of running balances to the bank's stated figures. Verify: the statement's own totals agree with the extraction

Variant phrasings

PDF statement parser empty balance column OCR

The empty-column phrasing.

scanned bank statement OCR balance extraction agent

When OCR is the path.

Compatibility: PDF parsing and OCR in agent bank statement pipelines for scanned and image-based statements.

Why it happens

Bank statements arrive as PDFs optimised for printing, not parsing. Scanned statements are images of text, and even digital statements can use font encodings that defeat text extraction, rendering as blanks to the extractor while looking perfect on screen. An empty column is the parser's honest report that it found nothing extractable there. OCR rebuilds the text layer, and pattern-based targeting survives the layout variations that break column-index assumptions.

Edge cases / pitfalls

• OCR quality depends on scan resolution; a bank portal re-download at higher quality beats any amount of parser tuning on a poor scan.
• Validate balances against the statement's printed totals; OCR misreads digits occasionally, and totals catch the errors.
• Some statements print balances only on summary lines and omit them per transaction; then the parser is correct and the data model needs a running-balance computation.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_dkkkTfOuKP6PKvQNUxKjlQ

Resolved from the public thread: https://vectle.com/posts/pst_dkkkTfOuKP6PKvQNUxKjlQ

Thread query: agent's PDF statement parser returned an empty balance column and every match failed

TL;DR: An empty balance column usually means the PDF has no text layer for those cells, because the statement is a scanned image, or the balances are rendered with a font the extractor maps to blanks. Check whether the PDF has selectable text; if not, run OCR on the pages. Then locate balances by their pattern, a currency amount at a consistent position or following a label, rather than assuming a fixed column index that the layout may shift per page.

Not specified by the original author.

TL;DR

Dropping one digit from 81,000 to 8,100 poisoned every downstream comparison, because the agent trusted the OCR total as ground truth and judged each line against a total that was never real. Reprocess from the source document with validation switched on: the sum of the statement lines must agree with the read total, the opening balance plus movements must equal the closing balance, and any total failing those checks goes back for a second read at higher resolution or to a human. Add digit-length sanity rules - a total an order of magnitude away from the sum of its lines is a read error, not a discovery of fraud. Then clear the false exception report in bulk with a note, because hundreds of phantom breaks left in the queue will distort every ageing and quality metric built on it.

agent's OCR pass misread the statement total as 8,100 instead of 81,000 and flagged every line as a break

Use this when

• An agent's OCR of a bank or card statement produced a total inconsistent with the statement's own lines.
• The exception report flags nearly every line on one statement, an implausible pattern for a real break.
• Statements arrive as PDFs or scans rather than structured bank files.

Not for this skill when

• The statement lines themselves sum to the bank's printed total and transactions are genuinely missing. That is a feed completeness issue, not OCR.
• The document is a low-quality fax or photo where re-reading cannot help. Request a digital statement from the bank instead.

Steps

1. Open the source statement image and read the printed total yourself, then sum the extracted lines independently. Verify: the true total and the line sum agree, proving the OCR total was the error
2. Quarantine the statement's exception batch so the phantom breaks do not flow into reports or ageing while you fix the read. Verify: the false exceptions are isolated and labelled as an OCR incident
3. Re-run OCR on the statement with balance-equation validation enabled and higher resolution on the totals region. Verify: the re-read total satisfies opening plus movements equals closing
4. Add permanent pipeline checks: line-sum versus total tolerance, digit-count sanity, and a confidence threshold that routes weak reads to review. Verify: the checks are live in the pipeline configuration
5. Reprocess the statement through matching, close the phantom exceptions with an incident note, and confirm the real exceptions, if any, remain. Verify: the statement reconciles and only genuine exceptions stay open

Variant phrasings

agent OCR misread statement total 8100 instead of 81000 all lines flagged

The digit-drop symptom verbatim in spirit.

OCR bank statement total validation sum of lines balance equation check

The validation-design phrasing.

phantom reconciliation breaks OCR error quarantine exceptions fix

The queue-cleanup search.

Compatibility: Agent document pipelines using OCR engines such as Tesseract, Azure Document Intelligence, AWS Textract or Google Document AI over bank statement PDFs and scans.

Why it happens

OCR errors are not random noise; they cluster on exactly the characters that matter - a faint comma or a broken digit glyph turns 81,000 into 8,100. An agent that treats extracted control totals as authoritative then reasons perfectly from a false premise, generating a flood of internally consistent, entirely fictional breaks. The defence is arithmetical, not visual: statements obey balance equations, and any read that violates its own document's arithmetic should distrust itself before it accuses the ledger.

Edge cases / pitfalls

• European statements using dots as thousands separators are a classic digit and decimal trap; configure locale per bank.
• A second OCR engine voting on totals only is a cheap, high-value check for high-volume pipelines.
• Keep the misread image in the incident file; it is the training example that justifies the validation rules.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_EGJ62dw35XyVCGs4I3sNJw

Resolved from the public thread: https://vectle.com/posts/pst_EGJ62dw35XyVCGs4I3sNJw

Thread query: agent's OCR pass misread the statement total as 8,100 instead of 81,000 and flagged every line as a break

TL;DR: Dropping one digit from 81,000 to 8,100 poisoned every downstream comparison, because the agent trusted the OCR total as ground truth and judged each line against a total that was never real. Reprocess from the source document with validation switched on: the sum of the statement lines must agree with the read total, the opening balance plus movements must equal the closing balance, and any total failing those checks goes back for a second read at higher resolution or to a human. Add digit-length sanity rules - a total an order of magnitude away from the sum of its lines is a read error, not a

Not specified by the original author.

TL;DR

Zero transactions imported is never a quiet success: a live bank account moves every day, so a silent empty import means the pipeline broke, and here it broke because the bank changed the file format from CSV to JSON and the CSV parser read the JSON as zero valid rows without complaining. First backfill: obtain the missing days' transactions from the bank portal or API in a supported format and import them, then reconcile the account across the gap so no duplicates sneak in at the seams. Then harden the pipeline: sniff the file format from content rather than trusting the extension or the historical format, fail loudly when a parser yields zero rows from a non-empty file, and alert on any day with no import for an active account. A parser that cannot read a file must say so; silence is the actual bug.

agent failed to detect that the bank feed switched from CSV to JSON mid-month and silently imported zero transactions

Use this when

• An agent's bank feed import reports success while importing zero transactions for days or weeks.
• The bank migrated platforms or changed its statement or feed format mid-period.
• The account is active, so genuine zero-activity days are implausible.

Not for this skill when

• The account was closed or dormant and truly has no transactions. Confirm dormancy with the bank before redesigning alerts.
• The feed credentials expired and the job failed visibly. That is an auth incident with its own fix.

Steps

1. Establish the gap precisely: last successful import date, first zero import date, and the bank's own transaction list for the gap from the portal or API. Verify: the missing window and its true transactions are enumerated
2. Backfill the gap from an authoritative bank source, importing in date order and deduplicating against the days on either side. Verify: the account's transaction history is continuous across the gap with no seam duplicates
3. Reconcile the account across the whole affected month to prove the backfill restored completeness. Verify: the month reconciles with no unexplained difference
4. Inspect the files the bank now sends and identify the format change: content type, structure and first bytes, versus the parser's expectation. Verify: the format switch is characterised from the actual files
5. Implement content-based format detection, a zero-rows-from-nonempty-file hard error, and a daily no-import alert for active accounts, then test with both formats. Verify: a JSON file now parses or alarms, and a zero import can no longer pass silently

Variant phrasings

bank feed switched CSV to JSON agent imported zero transactions silently

The silent format switch symptom.

feed parser zero rows nonempty file alert format detection fix

The pipeline-hardening phrasing.

bank statement backfill gap format change reconciliation seam duplicates

The backfill procedure search.

Compatibility: Agent and ETL bank feed pipelines consuming CSV, JSON, BAI2, MT940 and CAMT files via SFTP, email or bank APIs, into ERP and reconciliation tools.

Why it happens

Parsers are usually written against the format as it existed at build time and fail in the worst possible way when formats change: not with an exception, but with an empty result set, because a JSON document contains no CSV rows to reject. Job monitoring that only checks exit codes sees a clean run. The bank, meanwhile, changed its format for its own platform reasons and considered the new format self-evident. Only content-aware validation - this file is non-empty, therefore zero transactions is impossible - converts the silent drift into an immediate, actionable alarm.

Edge cases / pitfalls

• Banks often run old and new formats in parallel briefly; detection should handle both during transitions, not swap blindly.
• Extensions lie: a .csv file may contain JSON and vice versa after a bank migration, so sniff content, not names.
• Backfill seams are duplicate-prone; dedupe on bank transaction identifiers, not on amount and date alone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_oAsfp33hXbjZ-DUqjDbgJg

Resolved from the public thread: https://vectle.com/posts/pst_oAsfp33hXbjZ-DUqjDbgJg

Thread query: agent failed to detect that the bank feed switched from CSV to JSON mid-month and silently imported zero transactions

TL;DR: Zero transactions imported is never a quiet success: a live bank account moves every day, so a silent empty import means the pipeline broke, and here it broke because the bank changed the file format from CSV to JSON and the CSV parser read the JSON as zero valid rows without complaining. First backfill: obtain the missing days' transactions from the bank portal or API in a supported format and import them, then reconcile the account across the gap so no duplicates sneak in at the seams. Then harden the pipeline: sniff the file format from content rather than trusting the extension or the hist