agent's pdf parser dropped the second page of itemized folios

Not specified by the original author.

TL;DR

The parser read only the first page of multi-page hotel folios, so itemized charges on page two vanished from the audit. Change the parser to iterate every page, concatenate the extracted text in order, and validate that the extracted page count matches the PDF's page count. A page-count assertion turns silent drops into loud failures.

Error

agent's pdf parser dropped the second page of itemized folios

Steps

1. Confirm the drop: compare the parser's output against the full folio PDF. Expected: page-two charges (often incidentals and taxes) are missing from the output.
2. Check the parser code for a first-page-only read or a page-range default. Expected: the single-page assumption is visible.
3. Change the parser to loop over all pages in order and concatenate the results. Expected: multi-page folios produce complete text.
4. Add an assertion: extracted page count must equal the PDF's reported page count, else raise. Expected: future drops fail loudly instead of silently.
5. Re-parse the affected folios and re-run the audit checks. Expected: the missing charges appear and totals reconcile.

When to use

• A PDF parser drops pages from multi-page documents.
• Folio totals do not match the parsed line items.
• Validating parser completeness.

When not to use

• The parser fails on page one (a format problem, not a pagination problem).
• The PDF itself has only one page.
• The text extracts but misreads values (an OCR problem).

Tool compatibility

Applies to custom audit agents parsing PDFs (Python PDF libraries, cloud document APIs; current 2026 releases).

Variant phrasings

folio total exceeds the parsed lines

Later pages were dropped. Parse all pages and assert the count.

parser only read page one of the pdf

Loop the pages; never assume single-page.

multi-page receipts parsed incompletely

Concatenate pages in order and validate completeness.

Why it happens

Many PDF parsing snippets default to page one (sample code, quick prototypes), and the assumption survives into production because single-page receipts are the common case. Hotel folios, the documents most likely to be multi-page, are also the documents where the dropped pages carry the interesting charges (incidentals, taxes). The page-count assertion is the durable fix because it catches the bug class, not just this instance.

Provenance

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

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

Thread query: agent's pdf parser dropped the second page of itemized folios

TL;DR: The parser read only the first page of multi-page hotel folios, so itemized charges on page two vanished from the audit. Change the parser to iterate every page, concatenate the extracted text in order, and validate that the extracted page count matches the PDF's page count. A page-count assertion turns silent drops into loud failures.

Not specified by the original author.

TL;DR

A parser that drops pages quietly is worse than one that crashes, because the representment goes out missing its best page and nobody knows. Make page accounting a hard contract: count pages when the PDF lands, extract page by page and record success or failure per page, and refuse to build an evidence pack when extracted pages plus explicitly failed pages do not equal the source count. The usual culprits are scanned pages stored as images with no text layer, encrypted or malformed page objects, and a parser timeout that returns partial output as if it were complete.

fraud agent's pdf parser dropped chargeback evidence pages

Use this when

• Evidence summaries omit content that is visibly in the PDF.
• Multi page statements lose their final pages, often the totals page.
• The parser returns success with suspiciously short text on long files.

Not for this skill when

• Pages extract but the text is garbled from poor scan quality. That is the image quality gate problem.
• The PDF itself is missing pages at the source. Compare with the bank or customer original first.

Steps

1. Take one failing PDF and record its true page count and, per page, whether it has a text layer or is a scanned image. Verify: you have a page map to compare extraction against.
2. Run your parser and list which pages produced text, which produced nothing, and whether the run reported any warning. Verify: the dropped pages are named, not guessed.
3. Fix extraction per page type: OCR the image only pages, and treat parser timeouts and partial results as failures, never as complete output. Verify: the failing PDF now extracts every page or flags the specific pages it cannot.
4. Add the accounting gate to the pipeline: source pages must equal extracted plus failed, and a pack cannot be filed with failed pages unless a human accepts the gap on the case. Verify: a staged pack with a dropped page is blocked with the page named.
5. Log page accounting on every case so a later loss can be checked against what the parser actually saw. Verify: a sampled filed case shows full page accounting in its record.

Variant phrasings

pdf parser missing pages evidence

Missing pages phrasing.

chargeback pdf last pages not extracted

Final pages phrasing.

agent evidence extraction incomplete silent

Silent failure phrasing.

Compatibility: Any PDF extraction stack, PyMuPDF, pdfplumber, Tesseract OCR, or cloud document AI, in an agent evidence pipeline. Page accounting is stack agnostic.

Why it happens

PDFs are containers of mixed content: native text pages, scanned images, and occasionally damaged objects, all in one file. Simple extractors read the easy pages and skip the hard ones without an error, because skipping is not an exception in most libraries. An agent downstream sees clean, short text and reasonably assumes the document was short.

Edge cases / pitfalls

• Split and merged PDFs from banks can carry broken page trees. A repair pass with a tolerant tool often recovers pages a strict parser drops.
• Page counts can differ between viewers on files with hidden or deleted pages. Trust the parser count you validate, and record which tool counted.
• Do not let OCR confidence silently substitute for presence. A page can OCR confidently and still be the wrong page from a merged bundle.

Provenance

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

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

Thread query: fraud agent's pdf parser dropped chargeback evidence pages

TL;DR: A parser that drops pages quietly is worse than one that crashes, because the representment goes out missing its best page and nobody knows. Make page accounting a hard contract: count pages when the PDF lands, extract page by page and record success or failure per page, and refuse to build an evidence pack when extracted pages plus explicitly failed pages do not equal the source count. The usual culprits are scanned pages stored as images with no text layer, encrypted or malformed page objects, and a parser timeout that returns partial output as if it were complete.

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.