Splitters
What a Splitter does
A Splitter takes one file that contains several documents and breaks it into its separate parts. It reads every page, works out where one document ends and the next begins, classifies each segment against the document types you described, and sends each part onward on its own.
The common case is a scanner or a supplier that emails one PDF holding an invoice, a packing slip and a signed delivery note. Extracting that as a single document produces nonsense. A Splitter turns it into three documents that each reach the right flow.
A Collection answers “which flow does this document belong to?”. A Splitter answers “how many documents are in this file, and where does each one go?”. Use a Collection when each file holds one document of unknown type; use a Splitter when one file holds several.
How segmentation works
Every page is examined in order and assigned to exactly one segment. Segments never overlap and never leave a gap, so every page of the input ends up somewhere — there is no silent page loss.
The rules Tavnit applies when deciding where a document ends:
| Situation | What happens |
|---|---|
| Headers and logos repeat on every page | Not treated as a new document. A repeated letterhead across a five-page invoice is still one invoice. |
| The title, issuer, party, document number, format or date changes | Treated as a real boundary — a new segment starts. |
| Attachments, photos, quotes and screenshots | Always their own segment, even when they sit immediately before or after a matched document. |
| A segment matches none of your document types | Still produced, marked unmatched. It is never merged into a neighbour just to avoid an unmatched result. |
There is no confidence score. A segment either matches one document type or it matches none — the classifier is instructed to answer “no match” rather than guess. Unmatched segments are where you should look first when a split does not do what you expected.
Create a Splitter
A Splitter is a list of document types. Each one has a title, a description of what it looks like, and a destination. There are no samples to upload and no rules to write — the description is what the classifier matches against.
- 1Open Splitters and create a new one, named after the bundle it receives — Supplier delivery packets rather than Splitter 2.
- 2Add a document type for each kind of document in the bundle, with a title and a description of what appears on the page.
- 3Give each type a destination (see the table below).
- 4Upload a bundled PDF, or send one to the Splitter's email address.
- 5Open the completed split in Split History and check each segment's page range and match.
The description is the only thing distinguishing one document type from another. Write what a person would look at to tell them apart: “packing slip — lists quantities with no prices, signature box at the foot” beats “packing slip”.
Where each segment goes
Destinations are set per document type, not per Splitter. That is what lets one bundle fan out — invoices to an extraction flow, delivery notes to a Collection, everything else emailed to a person.
| Destination | What happens to the segment |
|---|---|
| Send to a flow | A normal extraction run is created for that segment, tagged with the Splitter it came from. |
| Send to a Collection | The segment is classified again by the Collection and routed to whichever flow matches. |
| Email it | The segment is emailed as a PDF to an address you specify. |
| Nothing | The segment is kept in the split result but not dispatched anywhere. |
A Splitter can feed a Collection, and a Collection can route to a Splitter. Tavnit refuses configurations that would form a cycle, and at run time a segment is never routed back into the Splitter that produced it — so a mis-set pair cannot spin documents in a circle and burn credits.
Segments dispatched to a flow carry their origin with them. The webhook payload for such a run includes the split it came from and the document type it matched, so you can trace a row back to the page range in the original bundle — see webhook payloads.
Sending files to a Splitter
A Splitter accepts files three ways: uploaded in the app, posted to the API, or emailed to its own address. The email route is the useful one — point a supplier or a scanner at it and bundles are broken up without anyone opening Tavnit.
- 1Open the Splitter and enable its Email Trigger.
- 2Copy the address and forward bundled PDFs to it.
- 3Each supported attachment becomes its own split.
Accepted attachment types and the reasons a file may be skipped are the same as everywhere else — see email integration. As with flows, if the trigger is switched off the mail is accepted and discarded without a bounce.
What splitting costs
A split is charged by the length of the source file: one credit per page of the bundle, regardless of how many documents come out of it. Each segment then pays its own extraction cost when it reaches a flow.
| Charge | When |
|---|---|
| 1 credit per page of the bundle | When the split runs. |
| The flow's own extraction charge | Per segment, once it reaches a flow. |
| 1 routing credit per segment | Only when the segment is sent to a Collection rather than straight to a flow. |
Sending segments straight to a flow is therefore cheaper than routing them through a Collection. Use the Collection destination when the document type genuinely could go to more than one flow; otherwise map the type directly.
Reading a split result
Open a completed split from Split History to see what the Splitter decided. Each segment lists its page range, the document type it matched, the reason for the match, and where it was dispatched.
- How many documents were found, and how many matched a configured type
- The exact page range of each segment, so you can check the boundaries against the original
- The reason the classifier gave for each match
- The run or Collection run each segment produced, with a link through to its results
- Segments that matched nothing — the first place to look when a split goes wrong
Wrong boundaries usually mean two document types are described too similarly. Wrong matches usually mean a description is too vague. In both cases the fix is in the document type descriptions, not in the file.