The AI Invoice Split action examines a single multi-page document, detects the boundaries between separate transactions inside it, and splits it into a new Record per transaction — automatically, as part of a workflow.


Use it when several distinct documents have been scanned or uploaded together as one file. A common case is a stack of invoices from different vendors captured in a single PDF: the action recognizes where one invoice ends and the next begins and breaks the pile apart so each invoice becomes its own Record.


Unlike keyword or barcode splitting, boundaries are found by content, not by separator sheets or page counts. For invoices the action identifies each transaction by its Vendor and Invoice Number; when two consecutive pages share the same identity they stay together, and when the identity changes a new Record starts.


AZURE ONLY: This is an AI action and runs only on Azure-hosted / AI-licensed sites.


How it differs from AI Classification (Split)

Both actions can break up a document, but they answer different questions:

  • AI Classification decides what each page is against a list of categories you supply, and splits pages within a single Record by type.
  • AI Split Detection decides where one transaction ends and the next begins by reading the documents' own identity — no category list — and creates a separate new Record for each transaction it finds.


Reach for AI Invoice Split when the incoming file is really many independent documents of the same kind (many invoices, many statements) that each deserve their own Record.



Header Indexing — for workflows that do not need line items

By default this action splits only: it creates one Record per invoice and writes nothing to them, exactly as AI Generic Split does. Turning Capture Header Fields on, on the Header Indexing tab, also captures each invoice's header values during the split and writes them onto the new Records as Invoice_Master_<name> values.


Read this before turning it on. Only header fields can be captured this way — line items cannot. If your workflow needs line items you have to run an AI Invoice Extraction action on every split Record anyway, and that action returns the header fields along with the lines. In that case this option saves you nothing at all: the run costs the same number of AI calls whether it is on or off. Most invoice processing does need line items, so for most invoice workflows this is not the option to reach for.


Where it does pay off is a workflow that never codes line items — approval routing on vendor, amount or PO number, a matching or de-duplication pass, or any triage step that only needs to know what each invoice is. The AI has to read each invoice's header to know where one invoice ends and the next begins, because it cannot find a vendor and invoice number boundary without reading the vendors and invoice numbers. With the option off those values are read and then discarded, and you recover them by running AI Invoice Extraction on every Record the split produced. A 150-page stack that splits into 80 Records then costs 81 AI calls: one to split, and 80 to re-read pages the split already read. With the option on, and no line items needed, it costs one.


The fields captured are the standard invoice header fields — Vendor and its address, remittance address, phone, fax and email, Customer Number, Invoice Number, Invoice Date, Due Date, PO Number, Currency, Terms, Subtotal, Tax, Shipping and Amount. They are exactly the header fields AI Invoice Extraction reads, under exactly the same names, so there is nothing to choose or list on the tab. If an invoice states payment terms and an invoice date but no due date, the Due Date is calculated from the terms in the same way AI Invoice Extraction calculates it.

The values arrive as Invoice_Master_<name> — the same convention AI Invoice Extraction uses — so the second half of the job is unchanged. Follow this action with Invoice Indexing, which moves Invoice_Master_<name> onto the real Record fields. Invoice Indexing makes no AI call at all, so running it 80 times costs nothing.


The symptom to watch for, if the option is on when it should not be: the Line Items mappings on your Invoice Indexing action produce nothing. They are not broken — nothing was ever captured for them to map. Put an AI Invoice Extraction action back into the process and they will fill in.


Why the values are prefixed

Invoice_Master_ is not decoration — it is what makes indexing during a split safe. When the action commits a split, every data value on the original Record is copied onto each new Record, and any field the split writes then overwrites what was copied. If the split wrote a captured value straight into a Record field, and that field happened to be one of the fields that decides which Record Type the Record resolves to, the new Record could silently land on the wrong Record Type. Writing into the separate Invoice_Master_ namespace cannot collide with a Record Type's filter fields, so this cannot happen. Invoice Indexing then applies the values deliberately, once you have said which field each one belongs in.


Options on the Header Indexing tab

  • Capture Header Fields — Off by default. On, the action captures the standard invoice header fields per invoice and writes them to each split Record as Invoice_Master_<name>. Off, the action captures only what it needs to tell the invoices apart, and you index each split Record afterwards with AI Invoice Extraction. Existing actions are unaffected — they keep splitting exactly as they did.
  • Extra Fields — Optional. Fields to capture beyond the standard invoice fields, one per line, for example "AccountNumber: the account number shown in the remittance block". Name each added field and describe it — a field named but not described is often missed, and a description with no clear name has nowhere to land. The values are saved as Invoice_Master_<name>, which is what the Custom Header rows on Invoice Indexing read, so an added field is mapped there rather than in the fixed rows above. Note this is a different box from Extra Instructions on the Advanced tab, which describes how to find invoice boundaries rather than what to capture.


When the AI is unsure

An invoice the AI split with low confidence gets an Invoice_Master_AIWarning value on its new Record explaining that the split should be verified. Because it is an ordinary data value you can search on it, or filter a workflow step on it, to route exactly those Records to a person for review while the rest carry on untouched.


What it works on

  • The action splits the active Record's document. The active document is used, or the Record's first document if none is active.
  • No OCR is required. The action reads the pages with vision AI directly.
  • Very large files are not supported — extremely long documents (roughly 100+ pages) will fail loudly rather than split partially.



When part of a split fails

A split turns one Record into many, and each new Record is created, given its own document, and started into workflow individually. A problem with one invoice does not stop the others. The action finishes the rest of the stack, and reports what went wrong, instead of abandoning the split partway through and sending the whole batch back to manual indexing. On a scanned batch of forty invoices, one bad document should not cost you the other thirty-nine.


Two things can go wrong with an individual invoice. It can fail to be created — a page that cannot be assembled into a document, for example. Or it can be created successfully and then fail on its way into workflow, which is much more common, because starting the new Record runs its workflow immediately and anything in that workflow can fail. An approval step that calls out to your accounting system, a merge template with a bad variable, or an AI extraction action that times out on an unusually long invoice will all surface here.


Where the failures are reported

The original Record — the one the action split — is where you look first. It carries a plain-English summary in @SPLITERROR, naming how many splits had problems and out of how many.

It also carries @SPLITERRORRECORDID, holding the ID of each failed Record as its own separate value. This is the field to automate against: because each ID is a value in its own right, a workflow step can walk them one at a time and act per Record.


Each failed new Record carries @SPLITROUTEERROR, holding the error for that Record specifically. This is the one that tells you why a particular invoice failed, and because it is an ordinary data value you can search on it or filter a workflow step on it.


Every failure also writes an entry to the Error Log, so a batch that quietly loses a few invoices overnight is visible the next morning without anyone having to read a workflow log.


The markers describe the most recent run only

@SPLITERRORRECORDID is cleared at the start of every split before any work is done. The values on a Record are always the current run's, never a running history. This is deliberate — a retry loop that picked up IDs from earlier runs would keep reprocessing invoices that were fixed weeks ago. If you need a history, copy the values elsewhere from within your own workflow, or rely on the Error Log entries, which are not cleared.


@SPLITERROR works the same way. A clean run clears it, so its presence always means the most recent split had a problem.


Building the retry or the alert

The straightforward pattern is a Search and Run Actions action (#122) that searches for Records with @SPLITROUTEERROR present. It runs your inner actions once per matching Record, with that Record active, so those inner actions can start its workflow again, send an email naming that invoice, or assign it to an AP clerk. Add whatever narrowing your site needs — a Record Type, a date range — so an old failure does not get picked up forever.


To drive the same work from the original Record instead, filter a workflow step on @SPLITERROR being present and loop the @SPLITERRORRECORDID values. This is the better shape when the notification should be one message about the whole batch rather than one per failed invoice.


Whichever you build, clear or update @SPLITROUTEERROR on a Record once it has been dealt with, so the same Record is not picked up on the next pass.


When nothing at all comes through

If every split fails, the action behaves as it always has: no split is committed, the original Record is left intact for manual indexing, and @SPLITERROR describes the failure. Partial success is what changed, not total failure. A split that produces nothing usable is still treated as a split that did not happen.



Options

The action's settings are grouped into five tabs.


Document

  • New Document Cat/Sub/Name — The Category, SubCategory and Name applied to each split Record's document. Leave blank to use the defaults.


Splitting

  • Commit Split — Controls what happens with the transactions the AI detects.
    • On (default): the action splits out a new Record per detected transaction and routes them automatically.
    • Off: the action does not commit the split. It stages the detected splits for a later Auto-Split Commit action (#91), so you can review or run other steps first.


Header Indexing

  • Capture Header Fields — Off by default. On, the action captures the standard invoice header fields per invoice and writes them to each split Record as Invoice_Master_<name>. Off, the action splits only and writes nothing to the new Records, and you index each split Record afterwards with AI Invoice Extraction. In earlier releases the off setting still wrote Invoice Number, Vendor, Invoice Date and Total onto each new Record under those names — if your process was relying on that, see If your split stopped filling in fields below.


AI Level

  • Quality — Vision split detection needs a capable model, so only two levels are offered:
    • Standard — good for most standard business documents.
    • Advanced — higher token cost; best for poor scans, dense pages, or subtle boundaries. 


Economy is intentionally not offered for this action as it would not do a good enough job.


Advanced

  • Extra Instructions — Free-form hints that describe boundary rules specific to your documents, for example "A remittance stub belongs with its invoice" or "A new PO number does NOT start a new invoice." Identity is driven by content (for invoices, Vendor + Invoice Number); when in doubt the AI keeps pages together rather than over-splitting.


TIPS

  1. If you want a person to review the detected splits before Records are created, turn Commit Split off and add an Auto-Split Commit action (#91) later in the process.
  2. Use Extra Instructions to teach the AI about attachments that belong to a transaction (remittance stubs, backup pages, terms sheets) so they aren't broken off into their own Record.
  3. The action favors keeping pages together when a boundary is ambiguous — if it is under-splitting, add an instruction describing what actually starts a new document; if it is over-splitting, describe what does not.
  4. Start with Standard quality and only move to Advanced if boundaries are being missed on poor scans or unusually dense pages.
  5. Before turning Header Indexing on, look at the Line Items mappings on your Invoice Indexing action. If they are filled in, this option will not reduce your token use — leave it off and keep AI Invoice Extraction in the process.
  6. Where it fits best is a first-pass triage: split the stack, index the headers, route on vendor or amount or PO number, and only run AI Invoice Extraction later on the invoices that actually reach coding.
  7. Add an Invoice Indexing action immediately after the split. Without it the `Invoice_Master_` values sit on the Records unmapped, which looks like the split failed to index when in fact only the second half is missing.
  8. Unlike AI Generic Split, this action does **not** need the Record to resolve to a Record Type in order to index. The invoice fields it captures are always the same ones, so they do not come from a Record Type.
  9. If your invoices carry a value the standard fields do not cover — an account number, a contract reference, a department code — add it in **Extra Fields** and map it in a **Custom Header** row on Invoice Indexing. It costs nothing extra, because it rides along in a call that is already happening.
  10. Filter a review step on `Invoice_Master_AIWarning` so a person sees only the invoices the AI was unsure about, rather than reviewing all of them.
  11. Add a step that watches for @SPLITROUTEERROR so a batch that loses an invoice tells you, rather than leaving it sitting with no work item and no approver. A Search and Run Actions action (#122) searching on that field is the usual shape.
  12. A failed Record still exists, still has its pages, and still has whatever the split captured for it. It only lacks a work item. Re-routing it is normally all the recovery it needs.
  13. If @SPLITERROR reports failures on every run at roughly the same point in a large batch, look at what the new Records' workflow does rather than at the split itself. The split had already succeeded for those invoices; something downstream is what failed.


NOTE ON (AI): Detecting splits with vision AI consumes tokens and may incur extra fees. Workflow tokens are billed separately from End-User or Admin tokens — check with your sales rep for more information.