“Scans receipts” is not one feature
You’re at dinner. Seven people. The check is $247. Both Splitwise and splitty will let you point a camera at that receipt. That is where the similarity ends, and where the only interesting question starts: what comes back?
What a split actually needs is every line item identified, assigned to specific people, with tax and tip distributed proportionally. A scanner that returns the merchant name and the grand total gets you as far as an equal split — which you could already do, because the total was printed at the bottom in the largest font on the page.
So receipt scanning is not a binary feature. The gap between “scans receipts” and “reads every line item accurately” is the difference between equal splitting and fair splitting. And that gap is wider than most people realize — including, as it turns out, wider than the standard benchmarks are set up to detect.
The numbers behind receipt scanning
Receipt OCR (optical character recognition) is a well-benchmarked problem in computer science. The ICDAR 2019 Scanned Receipt OCR and Information Extraction competition, organized by Zheng Huang, Kai Chen, and colleagues, ran one of the first standardized competitions for receipt scanning, built on 1,000 whole scanned receipt images split into a 600-image training set and a 400-image test set.
Its results are less flattering than “receipt scanning is a solved problem” suggests. On Task 3—pulling key fields out of a receipt—only one submitted method cleared 90%, and more than half scored below 80%.
The competition organizers were blunt about the gap between benchmark scores and what a receipt app actually needs. Their own assessment:
“If we take the strict requirement of receipt applications into account, say 99% accuracy, it is noted that, even the best OCR method in Task 2 can’t deliver the required performance.”
Huang et al., ICDAR 2019 SROIE competition report
That is the honest state of the art on a research benchmark: hard, unsolved, and worst exactly where receipts are messiest. Accuracy also varies dramatically depending on what the system is asked to extract—a distinction that turns out to matter more than the headline percentages, as the next two sections show.
Sources: Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction,” ICDAR (2019); Berghaus et al., “Multi-Modal Vision vs. Text-Based Parsing: Benchmarking LLM Strategies for Invoice Processing,” arXiv:2509.04469 (2025).
Why is a restaurant receipt harder to read than an invoice?
Because in the one head-to-head test we have, receipts came last. A 2025 benchmark by Berghaus and colleagues ran eight multimodal models from three families—Gemini 2.5, GPT‑5, and open-source Gemma 3 variants—over three document types. Prompts were tailored to each dataset, but the same prompt templates were used across every model within a processing strategy, so the models are comparable to each other. Receipts finished behind both invoice types for seven of the eight models tested.
Each figure is the best score any tested model reached on that document type — and each dataset is scored on its own field set, so read the table as three difficulty readings on the same models rather than one ranked exam. The benchmark’s authors describe their receipt set as “exhibiting a wide range of real-world variations including differing layouts, print quality, and image conditions (e.g., skew, lighting)” — which is a fair description of the piece of paper sitting under a water glass at the end of dinner.
The forty-point gap: reading the image vs. reading a transcript
The same study found something sharper. Each model was run two ways: looking directly at the receipt image, or reading a text version produced by a document converter first. On scanned receipts, native image processing hit 87.46%. The converter-first pipeline topped out at 47.00%.
Converting the receipt image to text before a model reads it cost roughly forty points of accuracy — and that penalty is measured on the header and total fields alone, the only fields this benchmark scores. Notably, the converter was not crude: the paper describes Docling’s output as maintaining “tables, sections, and other layout elements through markdown syntax,” while native processing “preserves all visual information and spatial context.” If even a structure-preserving conversion costs that much on a receipt’s header and total, an item table — where every price has to stay bound to the right name across a whole column — is at least as exposed. The benchmark does not measure that case, so treat it as the direction the evidence points, not as a measured result.
The researchers noted the same bottleneck: on their clean-invoice set, converter-first results clustered in a narrow 84–85% band across models, “effectively neutralizing the advanced capabilities of the larger, more powerful models.” On those runs, the pipeline, not the intelligence, looked like the ceiling.
This is why “does it scan receipts?” is the wrong question. In this benchmark, the same models landed forty points apart on the same receipts depending on whether they read the image itself or a text conversion of it. What a given app’s scanner reads is an implementation choice you cannot see from the outside.
Source: Berghaus et al., “Multi-Modal Vision vs. Text-Based Parsing: Benchmarking LLM Strategies for Invoice Processing,” arXiv:2509.04469 (2025). Accuracy is the share of fields extracted exactly right after minimal normalization. The authors note their datasets are open source and may appear in model training data.
What the receipt benchmarks actually score
Here is the part that gets lost when accuracy percentages get quoted: the headline scores from the standard receipt benchmark never grade the item table. The competition’s OCR tasks do score every word on the receipt, item text included — but no task grades whether an item name stays bound to its price as structured data.
ICDAR 2019’s Task 3 asks a system to extract four key fields from a receipt—company, address, date, and total amount. That is the ground truth. The 2025 benchmark above uses the same receipt dataset, so its 87.46% is measuring the same four fields. Both numbers describe how well a system reads the header and the total.
Neither one asks a system to bind “Caesar Salad” to “$14.00.” The item table—the part of the receipt an itemized split is built on—is not in the scored ground truth.
So a receipt scanner can post a strong benchmark number and still be useless for splitting. Reading the total accurately is what the benchmark rewards. Reading the item table is what a bill split requires. These are different capabilities, and the widely quoted numbers only measure the first.
This is a gap in what the benchmarks chose to measure, not a law of nature. A different corpus, CORD, annotates receipts specifically for line-item parsing: its authors collected over 11,000 Indonesian receipts (a 1,000-receipt sample is publicly released) and label them with five superclasses and 42 subclasses, including menu.nm (item name), menu.cnt (quantity), menu.unitprice, and menu.price. Item-level extraction is measurable. The standard receipt benchmark simply does not measure it.
Which means: when any app—splitty included—quotes a receipt scanning accuracy figure, the number worth asking about is accuracy at what. A total-only scanner and an item-level scanner can advertise similar percentages while doing entirely different jobs.
Sources: Huang et al., “ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction,” ICDAR (2019); Berghaus et al. (2025), which documents the SROIE annotation fields; Park et al., “CORD: A Consolidated Receipt Dataset for Post-OCR Parsing,” NeurIPS 2019 Document Intelligence Workshop.
Why the item table can’t be solved with a lookup list
There is an intuitive fix for reading item names: keep a dictionary of common menu items and match against it. splitty’s own receipt data says a dictionary would cover almost none of the table.
Across splitty’s US-leaning scanned restaurant receipts, the twenty most common line items—diet coke, espresso martini, french fries, water, and so on down the list—together account for under 4% of all scanned line items. The single most frequent item on the entire list is a diet coke, at well under half a percent.
That is an open vocabulary. Every kitchen names its dishes differently, abbreviates them to fit a receipt printer, and appends modifiers nobody standardized. There is no short list of expected names that covers it — whatever else an extractor brings to the job, a stock menu vocabulary contributes almost nothing. And when the name itself is unpredictable, the pairing of name and price is carried by the receipt in front of you — position, alignment, adjacency — not by prior familiarity with the dish.
Source: splitty first-party receipt data, 2026 snapshot of scanned US-leaning restaurant receipts. Shares are of all scanned restaurant line items; splitty does not publish counts. This aggregate measures item-name distribution only — it carries no OCR or parsing-accuracy dimension.
Feature-by-feature: what each app scans
Both apps have a receipt scanner. Comparing them honestly turns out to be harder than it sounds, because one side of the comparison is largely undocumented. Here is what we could actually verify, and where we couldn’t:
What this article deliberately does not claim. Our fetch of Splitwise’s App Store listing was rate-limited and came back empty, so this piece states no price for Splitwise Pro, no description of what its free tier includes, and no judgment about the quality of its OCR. Those are exactly the three numbers a comparison post usually leads with. We would rather leave a hole in the table than fill it with a figure we didn’t verify — and if you see those numbers quoted confidently elsewhere, it’s worth asking where they came from.
What the comparison does support is a difference in center of gravity. Splitwise’s scanner is an input to an expense ledger. splitty’s scanner is the foundation of the entire splitting workflow—every step downstream, from item assignment to shared plates to tax proportioning, depends on the scan returning a complete item table.
The gallery problem: When users asked to scan a photo they had already taken, Splitwise support replied that “our current receipt scanner doesn’t support this” — a request raised on Splitwise’s own feedback forum in August 2019 that is still marked open on the thread. Seven years is a long time for a feature request to sit under review.
How receipt OCR actually works
Modern receipt scanning uses a pipeline of machine learning models, not simple text recognition. Le, Pham, and Nguyen’s 2019 work on deep learning receipt recognition describes a system built from pre-processing to isolate the receipt area, a text-detection module, an attention-based text-recognition module, and an OCR verification step. Generalized — a wider frame than that paper’s own pipeline, which stops short of structured field extraction — a receipt scanner has to clear four hurdles, and each one can lose accuracy:
Image preprocessing
Correct rotation, skew, and lighting. Poor preprocessing cascades errors through every subsequent step.
Text detection
Locate text regions on the receipt. Differing layouts, variable print quality, and image conditions like skew and shadow all complicate detection.
Character recognition
Convert detected regions into text. This is where “Margherita Pizza” becomes “Margherita Pizza” or “Margh3rita Pizra.”
Field extraction
Classify text as item names, prices, tax, totals, or irrelevant information. This step determines whether the system understands the receipt’s structure.
The critical difference between receipt scanning implementations is how deep the pipeline goes. A system that stops after character recognition (step 3) gives you raw text. A system that completes all 4 steps gives you structured data: item names linked to prices, tax identified and separated.
Even the early hurdles are far from solved. Le, Pham, and Nguyen built and ran their pipeline — pre-processing, detection, attention-based recognition, and OCR verification, which stops short of the fourth hurdle above — on the same ICDAR 2019 receipt set discussed above, and reported their own system’s result: 71.9% F1 for the combined detection-and-recognition task. That number is not directly comparable to the field-extraction percentages elsewhere in this piece — it scores whether every word on the receipt was found and transcribed correctly, an earlier-stage job graded on a different metric than pulling out four known fields, so the two don’t rank against each other. But it makes the same point from the inside: even a purpose-built receipt pipeline, published by the people who built it, is reporting a result well short of “solved.”
splitty’s camera/OCR step is built to clear the fourth hurdle, not just the first three: it reads the itemized receipt and returns the line items as they are printed—each item and its price—because everything the app does next needs the item table, not the summary. What our sources record about Splitwise’s scanner is narrower: it opens the camera, and it feeds an itemized-bill flow. How deep its extraction goes is not something we could verify from anything published.
Source: Le, Pham & Nguyen, “Deep Learning Approach for Receipt Recognition,” arXiv:1905.12817 (2019); reported F1 is the paper’s own stated result on the Robust Reading Challenge on Scanned Receipts OCR and Information Extraction 2019 dataset, i.e., the same ICDAR 2019 receipts. The stage-4 field-extraction framing generalizes beyond that paper’s own two-module architecture; the ICDAR 2019 competition results are the evidence that key-field extraction scored lowest of the competition’s three tasks.
The manual entry error problem
When receipt scanning fails or isn’t available, people type numbers manually. Raymond Panko has catalogued what happens next. Reviewing audits of real organizational spreadsheets, he reports cell error rates—the share of cells containing an original error—of 1.1%, 2.2%, and 2.5% in the audits whose methodology was thorough enough to catch most mistakes. In laboratory experiments where every error could be detected, 51% of spreadsheets contained at least one error, despite most being only 25 to 50 cells in total size.
”Even the lower Butler [2000] values mean that even in spreadsheets of a few dozen cells, errors are likely.”
Raymond R. Panko, “Spreadsheet Errors: What We Know. What We Think We Can Do”
A restaurant receipt typed into an app is, functionally, a spreadsheet of a few dozen cells. Fifteen items, fifteen prices, a tax line, a tip line, and seven names to divide it across lands squarely inside the size range Panko is describing.
One honesty note from the same source: in the studies Panko reviews, the pure slip of mistyping a number “actually has been quite rare” — most of the errors behind those rates were logic and omission mistakes made while building the sheet. Typing a receipt is transcription plus arithmetic, so the mapping runs inexact in both directions. What carries over cleanly is the base result: in those experiments, about half of even the small hand-built spreadsheets contained at least one error.
And for splitting, any error compounds, whatever its type. A $18.00 line that ends up as $8.00 — whether mistyped, misread, or skipped and reconstructed from memory — means one person underpays by $10 and others overpay to compensate. The entire promise of fair splitting collapses if the underlying data is wrong.
Source: Panko, “Spreadsheet Errors: What We Know. What We Think We Can Do,” Proc. European Spreadsheet Risks Interest Group (EuSpRIG) (2000). Panko’s data is drawn from organizational and laboratory spreadsheets, not from restaurant receipts; the size comparison is ours.
Edge cases: where scanning quality is tested
Restaurant receipts are not standardized documents. They come from POS systems with wildly different formatting, in various states of crumpling and coffee-staining, printed at whatever quality the machine was last serviced for. The real test of OCR quality is how it handles these edge cases:
Print quality is one of the real-world variations the 2025 benchmark’s authors call out in their receipt set — “differing layouts, print quality, and image conditions (e.g., skew, lighting)” — and receipts are the document type where their models scored lowest, finishing last for seven of the eight tested. The benchmark doesn’t break scores out by condition; what it shows is that documents like these, in aggregate, are the hard case.
A “Split Appetizer Sampler” line item needs to be recognized and shared between specific people. In splitty a scanned item starts split among everyone, and you tap to remove the people who did not share it—so a shared appetizer is the default case, not a special one.
Some receipts show state tax, city tax, and a separate alcohol tax. Whatever those lines add up to, splitty distributes tax proportionally to each person’s share of the items rather than dividing it evenly across the table.
Receipts from sushi restaurants, dim sum spots, or regional restaurants may include non-Latin characters — a case the standard benchmark simply excluded. Its OCR task “will be restricted to words comprising Latin characters and numbers only,” and the organizers describe the dataset’s annotated text as mainly digits and English characters. Whatever a scanner’s benchmark score measures, it isn’t receipts like these.
Each edge case the scanner handles correctly is a manual step eliminated. Each one it misses puts someone back at the table squinting at a receipt and typing numbers. Multiply that across the overspending effect that equal splitting produces, and the accuracy gap becomes a fairness gap.
Why manual entry fails specifically at dinner
Panko’s error rates come from people sitting at desks, building spreadsheets they cared about, with time to check their work. That is the favorable condition. Fifteen prices typed into a phone at a loud table, mid-conversation, while a server waits, is the same task under worse conditions — and nobody has run the study that would tell you how much worse.
So take the mechanism as our inference and the numbers as the measured part: the error rate on small hand-built spreadsheets is already non-trivial in a quiet room, and a restaurant table is not a quiet room. This is the same mental math problem that makes bill splitting hard in the first place, showing up one layer down in the data entry.
Scanning changes the shape of the job. The camera captures the receipt, the model extracts it, and the person’s remaining task is verifying and assigning rather than transcribing. Checking a list you can see against a receipt you’re holding at least gives you something concrete to check; producing that list from scratch gives you nothing to check until you’ve typed the whole thing.
Source: Panko, “Spreadsheet Errors: What We Know. What We Think We Can Do,” Proc. EuSpRIG (2000). The extension from office spreadsheets to a restaurant table is ours, not Panko’s finding.
Fit, not capability: the real comparison
Almost every app comparison is written in the language of capability: does it have the feature, yes or no. That framing is what produces a checkbox labeled “receipt scanning” with a tick next to both apps, and it is why those comparisons are useless.
The better question is fit. “Does it scan receipts?” measures capability. “Does it produce the data that this particular task consumes?” measures fit — and only the second one predicts whether you finish dinner without a calculator. The benchmark sections above are the same point in research form: a system can score well on the fields it is graded on and still not return the field you need.
Applied to receipt scanning for bill splitting, the two apps have genuinely different shapes:
Expense ledger, with a scanner attached
Splitwise’s center of gravity is the running balance between the same people over time. The receipt scanner is one input into that ledger.
Receipt scanner with splitting built around it
The entire app is designed starting from the receipt scan. Every feature—item assignment, shared plates, tax distribution—flows from the extracted data.
Read as a fit question rather than a feature question, the answer stops being contested: for “split this restaurant bill right now,” a purpose-built receipt scanner is the better shape. For “track what we owe each other over a week-long vacation,” Splitwise remains the better tool. Splitwise tracks; splitty settles.
Why what the scan returns changes fairness outcomes
Uri Gneezy, Ernan Haruvy, and Hadas Yafe’s landmark 2004 field experiment put diners in a restaurant under different payment rules. Their finding, in their own words: “subjects consume more when the cost is split, resulting in a substantial loss of efficiency.” Diners preferred paying individually—and when forced into the split-bill rule, they “minimise their individual losses by taking advantage of others.” The contrast condition in the experiment was individual pay: each person pays for what they ordered. The authors are careful about scope — they made “a conscious effort… not to invite students who were familiar with each other,” and they note that among friends, where the situation repeats, it “may in fact be individually and socially optimal to split the bill.”
The bridge from their result to scanning is ours, not the study’s: an itemized split applies the individual-pay principle at settlement time, and that requires accurate item-level data. If the receipt scanner only captures the total, you’re back to dividing equally—carrying whatever overconsumption incentive that rule carries for your table. If the scanner misreads a $28 steak as $18, someone underpays by $10 and the remaining diners absorb the difference without knowing.
Three diners: one pizza, one steak, one salad, with the $24 platter shared three ways at $8 each. With total-only scanning, $106.70 gets divided by 3: $35.57 each. With item-level scanning and proportional tax, each person pays their own items plus their share of the platter, grossed up by the same 8.875%: the salad person pays $23.95, the pizza person $28.31, and the steak person $54.44. The salad person was overpaying by $11.62; the steak person was underpaying by $18.87. The three itemized shares still add up to $106.70—that is the difference an item-level scan makes.
Source: Gneezy, Haruvy & Yafe, “The Inefficiency of Splitting the Bill,” The Economic Journal (2004).
How the research maps onto splitty’s design
splitty’s receipt workflow lines up with what this research keeps finding. Here is the map from finding to design choice — justification, not a documented design history:
When Splitwise is still the right choice
Honest comparison requires acknowledging where the competitor wins. splitty isn’t for everything, and neither is Splitwise. Here’s the honest breakdown:
Use Splitwise when: you need ongoing expense tracking with roommates, multi-day trip accounting, or running balances across weeks or months. Splitwise’s ledger architecture is purpose-built for these scenarios, and splitty deliberately does not do them.
Use splitty when: you need to split a specific restaurant bill right now. Item-by-item. With tax and tip distributed proportionally. And payment requests sent before everyone leaves the table. This is what receipt-first design does differently.
One last thing worth naming, because it applies to every scanner including ours: a tool that shows you only a final number is a tool you cannot audit. If the app hands back “$247” you have no way to know whether it read the receipt correctly — you can only accept or reject the whole thing. An app that hands back fifteen named line items is showing its work, and showing your work is what makes verification possible at all. That is an argument for item-level extraction independent of any accuracy percentage either app might advertise.
Frequently asked questions
Does Splitwise have receipt scanning?
Yes. Splitwise’s own support team referred to “our current receipt scanner” in an August 2019 feedback thread, and the request that prompted it describes scanning a receipt “for making an itemized bill.” What we could not verify from any source we were able to retrieve is what Splitwise charges for it, what its free tier includes, or how much of the item table the scan returns — so this article doesn’t state any of the three. Our fetch of the App Store listing was rate-limited and came back empty.
Which bill splitting app has the best receipt scanning?
Ask what the scanner returns, not what percentage it advertises. splitty reads the itemized receipt and returns the line items as printed, so each item can be assigned to the people who shared it. That is the capability an itemized split depends on. Be skeptical of accuracy percentages generally—splitty’s included: as the sections above show, the standard receipt benchmark grades header and total fields rather than the item table, so the accuracy figures vendors quote are not grounded in these benchmarks’ scoring of the part a split actually uses. Our full comparison covers additional apps.
Can Splitwise scan receipts from photos?
Not per Splitwise’s own last word on it: support replied that the scanner did not support scanning from a saved image when the request was raised on Splitwise’s feedback forum in August 2019, and the request is still marked open there. If that has changed since, it hasn’t been announced on the thread.
Is splitty better than Splitwise for restaurant bills?
For splitting a specific restaurant bill in real time, yes. For tracking shared expenses over weeks or months (roommates, trips), Splitwise is better suited. They solve different problems.
FAQ
Receipt scanning comparison questions
01 Does Splitwise have receipt scanning?
Yes. Splitwise support referred to 'our current receipt scanner' in an August 2019 feedback thread, and the request that prompted it describes scanning a receipt for making an itemized bill. What we could not verify from any retrievable source is what Splitwise charges for receipt scanning, what its free tier includes, or how much of the item table the scan returns — so this article states none of the three.
02 Which bill splitting app has the best receipt scanning?
Judge a receipt scanner by what it returns, not by an advertised percentage. splitty reads the itemized receipt and returns the line items as printed, then distributes tax and tip proportionally to each person's share. The standard receipt benchmark grades header and total fields rather than the item table — the best of eight 2025 models tested reached 87.46% on scanned receipts — so those benchmark scores say nothing about line-item extraction.
03 Can Splitwise scan receipts from photos?
Not per Splitwise's own last word on it. When users requested scanning from a saved image on Splitwise's feedback forum in August 2019, Splitwise support replied that the scanner did not support it, and the request is still marked open on the thread.
04 Is splitty better than Splitwise for restaurant bills?
For restaurant bills specifically, yes. splitty is built around the receipt scan: it reads the line items, splits each one among the people who shared it, distributes tax and tip proportionally, and sends each person a pre-filled payment request. Splitwise excels at ongoing expense tracking between roommates and multi-day trip accounting.
