All posts
    AP AutomationInvoice CaptureDocument ProcessingOracle EBS

    When one scanned PDF holds five invoices: splitting batch scans into individual records

    June 6, 20256 min readBy Founder, EZ Cloud

    Plenty of accounts payable still runs on paper at the front end. Suppliers mail invoices, a mailroom or AP clerk drops the whole stack into a multi-function scanner, hits scan, and out comes one PDF containing a dozen different invoices — sometimes with a remittance stub, a packing slip, or a signed delivery note tucked behind each one.

    That single file is a problem the moment it lands. AP doesn't need a document; they need each invoice as its own record, owned by the right person, matched to its own PO, and posted as its own payable. Treating the scan as one unit and treating it as a dozen separate invoices are very different operations — and the gap is where a lot of manual sorting still happens.

    Why a batch scan is harder than it looks

    The naive approach is to make a human do it: open the big PDF, figure out where one invoice ends and the next begins, split it page by page, save each piece, and key them in. On a high-volume day, that's hours of tedious, error-prone work before any actual AP processing starts.

    Several things make automatic splitting genuinely hard:

    • Invoices aren't a fixed length. One invoice is a single page; the next is four pages plus a two-page itemized backup. You can't split every N pages.
    • Backup documents belong with their invoice, not on their own. A packing slip behind invoice #3 is supporting documentation for invoice #3 — it must travel with it, not become a phantom fourth "invoice."
    • The scanner doesn't know where the boundaries are. It just feeds paper. Nothing in the raw image stream says "new invoice starts here" unless something in the process puts it there.

    Get the boundaries wrong and you get the worst of both worlds: two invoices merged into one record (so one gets paid and the other silently disappears), or one invoice split across two records (so it's processed — and potentially paid — twice).

    Separator pages: making the boundaries explicit

    The reliable way to solve this is to stop guessing where invoices begin and instead make the boundary explicit and machine-detectable. The common, low-tech, and surprisingly robust method is a separator page: a simple, recognizable sheet placed between documents in the stack before scanning. It can carry a barcode, a distinctive pattern, or a recognizable marker — the point is that it's unambiguous.

    When the batch PDF is processed, the system scans for those separator pages and uses them as the cut points. Everything between one separator and the next is treated as a single document — the invoice plus whatever backup pages sit behind it. The separator pages themselves are discarded; they're scaffolding, not content.

    This turns an unstructured stack into a clean sequence of individual documents without anyone having to interpret page content by eye. The mailroom inserts a separator between each invoice as they prep the stack — a fast, mechanical step — and the splitting is then deterministic rather than a judgment call.

    Each split becomes a real invoice record — with its own ownership

    Splitting the file is only half the job. The output of a batch scan shouldn't be a folder of smaller PDFs that someone still has to import one at a time. Each split should land as a first-class invoice record in the AP workflow, ready for extraction, coding, matching, and approval — exactly as if it had arrived as a standalone file.

    That means each new record gets:

    • Its own identity. A distinct invoice in the queue, not a fragment of a parent document.
    • Its own ownership and routing. Each invoice flows to the team member responsible for it, picking up the same approver-assignment rules any individually submitted invoice would.
    • Its own supporting documents, kept together. The packing slip, delivery note, or remittance stub scanned behind an invoice stays attached to that invoice, so the approver and any future auditor can see the full backup in one place.
    • Its own audit trail. Where it came from, when it was split out, and everything that's happened to it since.

    Once the file is broken into proper records, the rest of automation works normally. AI extraction reads each invoice's fields, matching runs per invoice, and the supporting documents ride along — so the fact that ten arrived in one scan becomes invisible downstream. The batch scan was just an input format, not a special case the pipeline has to know about.

    Don't lose the original

    One discipline matters for audit and dispute handling: keep the original batch scan, intact, alongside the split records. If a question ever comes up about how an invoice was separated — or whether a page ended up attached to the right invoice — you want the source available, not just the pieces. Splitting should be additive: individual records without destroying the evidence of how they were produced.

    Where EZ Cloud fits

    Multi-invoice batch scans are one of those unglamorous realities that separate AP automation built for demos from AP automation built for the way finance teams actually receive documents. We handle separator-page detection and splitting as part of capture — one scanned PDF becomes many invoice records, each with its own ownership, its own backup documents kept attached, and its own audit trail — feeding the same AI extraction and exception-handling pipeline as any other invoice, and posting natively into Oracle EBS and Fusion.

    If your team is still hand-splitting scanned stacks before the real work starts, that prep time is pure overhead — and letting the scan split itself cleanly is one of the faster wins in front-end AP.

    See it against your Oracle AP

    Book a 30-minute walkthrough — we'll run a real exception from supplier email to Oracle posting, on Fusion or EBS.