How do I extract line items when they span multiple pages?

Each of these is easy to spot once you know its signature, and each has a structural fix rather than a tuning fix.

• Repeated headers: "Date | Description | Amount" appears on every page and becomes a row whose amount is null or zero.
• Carried-forward double counting: page two opens with the page-one subtotal, which then gets added again into your sum.
• Split rows: a long description wraps across the page break and produces two rows, one with an amount and one without.
• Order scrambling: pages processed in parallel come back out of order, so a running balance no longer runs.

The structural fix is to stop splitting. When the extractor sees the whole document, continuation is visible: it can tell that the row beginning on page two is the tail of the row that started on page one, and that the line reading "Balance carried forward" is not a purchase.

On Dokyumi that has a specific, predictable price. One credit covers a document of up to 5 pages, and a document consumes one more credit per additional 5 pages. Self-serve plans stop at 50 pages per document. So a 12-page statement is one API call and 3 credits, not 12 metered pages. If your documents routinely exceed the self-serve ceiling, that is an Enterprise conversation rather than a reason to start chopping files.

One caveat worth planning for: splitting a document to dodge a page limit re-creates every failure mode listed above. If you must split, split at a boundary the document itself defines — a section, an account, a statement period — and never mid-table.

Add two fields that are not "data" in the business sense but make verification possible: a row type and a page number. Row type turns the summary lines into labelled objects you can filter out. Page number gives you a way to spot ordering problems and to point a reviewer at the right sheet of paper.

Both are model-produced values like everything else in the response, so treat them as claims to be checked rather than facts. The check is cheap: page numbers should be non-decreasing down the array, and the count of item rows should match any row count the document states.

Most business documents that run to multiple pages print at least one control total: an invoice total, a closing balance, a page count, sometimes an explicit line count. Capture those as separate fields and let your code compare.

Three comparisons cover the failure modes. Item rows must sum to the stated total. The extracted row count must match a stated count when one exists. And no item row may duplicate a carried-forward value — that specific coincidence is the double-count signature, and catching it automatically is worth more than an hour of manual checking.