Why the receipt total alone isn't enough
A receipt total tells you how much was spent. It doesn't tell you whether $84 at a grocery store was entirely office supplies, entirely a personal purchase mixed in by mistake, or a bit of both — and it doesn't, on its own, tell you which line on a card statement that receipt actually corresponds to when three purchases from the same merchant landed the same week. Both of those problems need the receipt broken into its individual line items, not just its bottom line.
Both problems compound at scale. A platform processing a few dozen receipts a month can absorb the cost of a category guess being slightly wrong, or a human spending a minute confirming a match by hand. A platform processing thousands of receipts a month cannot — the same small inaccuracies multiply into a meaningful data-quality and labor-cost problem, which is exactly why line-item extraction and matching become more valuable, not less, as a spend platform grows.
What line-item matching actually does
Two capabilities, used together by most expense platforms: first, every item a receipt itemises — description, quantity, unit price — comes back as its own entry in the extraction response, not folded into one total. Second, the receipt as a whole is compared against the transactions on a card or bank statement your platform already holds, and the closest match by amount, date and merchant is identified, so a submitted receipt links automatically to the charge it explains.
The line_items array, in detail
"line_items": [
{ "description": "Copy paper, 5 reams", "quantity": 5, "unit_price": 6.20 },
{ "description": "USB-C cable", "quantity": 2, "unit_price": 9.99 },
{ "description": "Energy drink", "quantity": 1, "unit_price": 3.15 }
]Each entry keeps its own description exactly as printed, so a policy engine or an approver can see precisely what was purchased, not a merchant-level category guess applied to the whole receipt.
Matching a receipt to its statement transaction
Once a card statement has been extracted (see the core API page for the statement schema), each transaction row is a candidate for matching against a submitted receipt. The match compares three signals — amount (exact or within a small tolerance for a tipped restaurant charge), date proximity, and merchant-name similarity — and returns the strongest candidate along with a confidence score.
This matters most at the volume most spend platforms actually operate at — hundreds or thousands of receipts a month, where manually comparing each one against a statement is either a dedicated headcount cost or, more commonly, a step that simply doesn't happen and the reconciliation gap just accumulates unnoticed. Automated matching turns that into a background process that only surfaces the exceptions genuinely worth a person's attention.
Itemised policy checks
A spend policy that caps meal spend at $75 or flags alcohol purchases needs to evaluate individual items, not a receipt total that might mix a compliant $60 meal with a $40 bottle of wine on the same bill. With line items returned individually, your policy engine can apply category-specific rules per item and flag only the lines that actually violate a rule, instead of rejecting or manually reviewing the entire receipt.
Split-category expensing
The same capability handles the common case of one receipt covering more than one GL category — an office-supply run that also picks up a personal item, or a hardware-store receipt split between a client-billable project and general overhead. Each line item can be coded to its own category and its own cost center, rather than forcing a single category choice for the whole receipt.
Why item-level data changes what's possible
Most expense platforms are built around the receipt as the atomic unit — one receipt, one expense line, one category, one approval decision. That model works fine until a real receipt doesn't fit it, which happens more often than it might seem: a grocery run that's partly office supplies, a hardware-store trip split across two client projects, a team dinner where the alcohol needs separate policy treatment from the food. Every one of those cases is either forced into a single category (losing accuracy) or requires a human to manually split the receipt (losing the automation the platform was supposed to provide).
Line-item data resolves that tension by moving the atomic unit down one level, from the receipt to the individual purchase. A policy engine, a cost-allocation system or a client-billing workflow can then operate on the unit it actually cares about, rather than being forced to treat a multi-category receipt as if it were a single, uniform expense.
What building this matching logic yourself involves
Even with structured receipt data in hand, matching it to statement transactions and evaluating per-item policy rules is itself a non-trivial piece of engineering — fuzzy merchant-name comparison, date-window tolerance, amount-matching with tip and tax variance, and a confidence scoring system to decide when a match is reliable enough to trust automatically versus when it needs a human to confirm. Building that logic well, and tuning it against your own real receipt and statement mix, is commonly several weeks of focused engineering work even once the underlying extraction is solved.
The confidence signal and structured line-item data returned by this feature are specifically designed to make that remaining engineering work smaller — you're tuning thresholds and building a review UI around data that's already reliably structured, rather than also solving the extraction and structuring problem from scratch.
How it works
Extract the receipt
POST /extract returns the full line_items array alongside merchant, tax and total fields.
Reconcile line items against the subtotal
The sum of extracted line items is checked against the receipt's own printed subtotal before the result is returned.
Compare against candidate statement transactions
Your integration compares the receipt's amount, date and merchant against the statement rows you already hold.
Apply your policy rules per line item
Category limits, alcohol flags or client-billable splits run against individual items, not the receipt total.
A worked example: a client dinner receipt
A $146.80 restaurant receipt submitted for a client dinner itemises three courses, two glasses of wine and a bottle of water, plus tax and an 18% tip. The policy caps alcohol reimbursement at $30 per person for two attendees.
| Line item | Amount | Policy check |
|---|---|---|
| 3 entrées | $78.00 | Within meal policy |
| 2 glasses of wine | $24.00 | Within $60 alcohol cap for two |
| 1 bottle water | $5.00 | Within meal policy |
| Tax + 18% tip | $39.80 | Standard, not itemised further |
Without line-item data, this receipt either passes or fails as a whole; with it, the alcohol spend specifically is checked against its own cap while the rest of the meal is approved normally — the distinction most real spend policies actually need to enforce.
Match confidence and ambiguous cases
Two coffee-shop purchases from the same merchant on the same card the same afternoon are genuinely ambiguous to match by amount and date alone. Rather than guessing, a match below a confidence threshold is returned as a ranked list of candidates instead of a single answer, so your UI can prompt a quick human confirmation on the small fraction of cases that need it.
When a receipt has no matching statement line
A receipt submitted before its statement has posted, or paid on a personal card for reimbursement rather than a corporate card, has nothing to match against yet. It's returned as unmatched rather than forced onto an unrelated transaction — most platforms hold it in a pending-match state and re-run the comparison once the relevant statement period is extracted.
Split payments across cards
A bill split across two cards at the table — common for team dinners — produces two statement transactions for what was, on paper, one receipt. Each card's portion is matched independently against its own statement line by amount, so a split payment doesn't need special-cased handling beyond running the match twice, once per card.
Cases this is built to handle cleanly
A receipt with a discount or coupon applied
The discount, where printed, is its own line item, and the reconciliation check confirms the final total still accounts for it.
A tip added after the printed subtotal
Recognised as a distinct amount from the itemised goods, not folded incorrectly into a line item's price.
A merchant that renamed itself on the statement vs. the receipt
Fuzzy merchant-name matching tolerates common abbreviations and legal-entity suffixes that differ between the two documents.
A receipt for a partial refund or exchange
Extracted with whatever the receipt itself prints — a negative line item where the merchant shows one.
Who this matters most for
Corporate-card platforms automating reconciliation
Removing the manual step of matching a submitted receipt to the right statement line.
Platforms enforcing itemised spend policy
Category or per-item limits that a receipt total alone can't evaluate correctly.
Agencies and consultancies billing clients from receipts
Splitting a single receipt across billable and non-billable line items.
Finance teams auditing expense data at the item level
A genuine line-item record instead of a merchant-level category guess.
What this means for audit and compliance review
A finance team preparing for an internal or external audit generally needs to demonstrate not just that an expense was approved, but that it was approved against the correct evidence — the specific items on a receipt, not just its total. Line-item data preserved alongside the match to its statement transaction gives an auditor exactly that trail: what was purchased, what it cost individually, which policy rule it was checked against, and which statement charge it corresponds to, all traceable from a single expense record rather than reconstructed after the fact from a stack of paper receipts.
For platforms serving regulated industries or larger enterprise customers, this level of evidence detail is frequently a specific, named requirement in a vendor security or compliance questionnaire — having it available natively, rather than as a manual process bolted on before an audit, is often the difference between a smooth review and a scramble.
What this feature doesn't do
Doesn't encode your specific policy rules
It returns the structured data a policy engine needs — the actual limits, categories and approval logic are configured on your side.
Doesn't guess a match below the confidence threshold
An ambiguous case is surfaced as candidates, never silently resolved to a best guess.
Doesn't require the statement to have been extracted through FlowParse
Matching works against any statement transaction data your platform already holds, in whatever shape you provide it.
Security and privacy
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing you upload is ever used to train AI models.
Full details are on the security page.
Get your API key
Extract a real receipt and inspect its line_items array directly. See the full API overview for the complete response schema, or the integration guide for a step-by-step walkthrough. No credit card required.