Get the App Get the App
MenuClose
Get the App

Splitwise receipt scanning vs splitty: which OCR is better?

Updated Oct 24, 2026 · 21 min read

Both apps point a camera at your receipt. What comes back is the whole question—and the benchmark behind the headline accuracy scores grades the header and the total, never the item table a split actually needs.

“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%.

90.49%Best Hmean on ICDAR 2019 Task 3, key information extraction — the only entry above 90%
87.46%Best accuracy among the eight 2025 multimodal models tested on those same scanned receipts
47.00%Best score on those same receipts when the image is flattened to text before any model reads it

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.

Document typeBest accuracyWhat makes it hard
Clean digital invoices96.50%Synthetic, structured, generated as data
Scanned invoices92.71%Stamps, handwriting, variable print quality
Scanned receipts87.46%Differing layouts, print quality, and image conditions like skew and lighting

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.

~96%of splitty’s scanned restaurant line items fall outside the twenty most common item names. The item table is a long tail, not a short menu.

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, and both can split a restaurant receipt item by item: Splitwise through Pro, and since October 2026 through Itemize, which is free in the US and UK. Here is what each one documents, from Splitwise’s own help center, Pro page, and launch announcement:

Scanner behaviorSplitwise (what our sources show)splitty
Scan inputCamera. A request to pick a saved image from the gallery has been open since August 2019, when Splitwise support replied that “our current receipt scanner doesn’t support this.”Camera capture of an itemized receipt
What the scan feedsPro: the scan creates an expense and detects the individual items. Itemize (free in the US and UK since October 14, 2026): one person photographs a restaurant or bar receiptThe line items as printed: each item and its price
Assigning items to peoplePro: assign each item to specific people. Itemize: everyone joins by QR code, without the app or an account, and claims their own and shared itemsItems start split among everyone; tap to remove whoever didn’t share one
Tax and tipItemize: proportional tax and tip included in each person’s totalDistributed proportionally to each person’s share
What happens afterItemize: settle with Splitwise Pay, with cash, or by adding the expense to a running Splitwise balanceA pre-filled payment request to each person, in their preferred payment app

What this article deliberately does not claim. Splitwise’s help center lists receipt scanning and itemization as Pro features, and its US App Store listing shows Pro in-app purchases from $2.99 to $39.99 without naming the plans. Itemize is the exception: Splitwise says it is free for all users in the US and the UK, with more markets planned. What we can’t give you is a judgment about the quality of either app’s OCR, because we found no public benchmark that tests it. If you see an accuracy number quoted confidently for either app, it’s worth asking where it came from.

With Itemize, the two flows now look alike at the table: one person scans, the items get split, tax and tip follow each person’s share, and nobody else needs the app. The differences are in who does the splitting and where the money goes. In Itemize, each guest claims their own items. In splitty, items start split among everyone and the person holding the phone taps to remove whoever didn’t share one. Itemize settles through Splitwise Pay, cash, or the Splitwise balance; splitty sends each person a pre-filled request in the payment app they already use. And Itemize is US and UK only for now.

Sources: Splitwise, “Splitwise Launches New Feature For Receipt Splitting,” press release (October 14, 2026); Splitwise Help Center, “What is Splitwise Pro?”; Splitwise on the US App Store (in-app purchases, checked October 2026).

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:

1

Image preprocessing

Correct rotation, skew, and lighting. Poor preprocessing cascades errors through every subsequent step.

2

Text detection

Locate text regions on the receipt. Differing layouts, variable print quality, and image conditions like skew and shadow all complicate detection.

3

Character recognition

Convert detected regions into text. This is where “Margherita Pizza” becomes “Margherita Pizza” or “Margh3rita Pizra.”

4

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. Splitwise describes its scanner as reaching the same stage: Pro “will detect the individual items so that you can assign them,” and Itemize turns the photo into items each guest can claim. How accurately either app does that is not something anything published lets us verify.

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:

Faded or low-contrast print

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.

Shared items (split plates)

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.

Multiple tax lines

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.

Foreign character sets

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.

51%of spreadsheets built in controlled experiments contained at least one error — and most were only 25 to 50 cells, about the size of a dinner receipt typed by hand (Panko).

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:

Splitwise

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.

Built for ongoing balances between the same group
Handles multi-expense, multi-week accounting
Free Itemize (US and UK): guests claim their own items by QR code, with proportional tax and tip
Outside the US and UK, scanning and itemizing are Pro features
No saved-photo scanning per Splitwise support’s 2019 reply — the request is still open
splitty

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.

Reads the itemized receipt and returns the line items
Items start split among everyone; tap to remove
Tax and tip distributed proportionally
Sends each person a pre-filled payment request
No ongoing ledger or running balance over time

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.

Margherita Pizza$18.00
NY Strip Steak$42.00
Caesar Salad$14.00
Shared Appetizer Platter$24.00
Subtotal$98.00
Tax (8.875%)$8.70
Total$106.70

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:

ICDAR 2019: key-field extraction scored far below text detection and OCR — only one entry cleared 90%→splitty’s scan targets the item table itself, not just the header and total
Berghaus et al. (2025): flattening a receipt to text before reading it cost roughly forty points of accuracy→no scanner’s internals are inspectable from the outside, so splitty is meant to be judged on its output — the line items as printed, there to check against the paper in your hand
splitty’s own receipt data: the twenty most common line items are under 4% of all scanned US-leaning restaurant line items→extraction reads what is printed on the receipt in front of it rather than matching against a menu vocabulary
Panko: in the most thorough audits, cell error rates ran 1.1–2.5%, and 51% of spreadsheets built in experiments contained an error→splitty eliminates manual entry entirely—scan, verify, assign instead of type, calculate, hope
Gneezy, Haruvy & Yafe (2004): people consume more when the cost is split, at a substantial loss of efficiency→splitty splits by item: each item starts shared by everyone, and one tap removes whoever didn’t have it, so splitting by item takes no more effort than splitting evenly

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.

FAQ

Receipt scanning comparison questions

01 Does Splitwise have receipt scanning?
Yes. Splitwise’s help center lists receipt scanning and itemization as Pro features. Since October 14, 2026, Splitwise’s Itemize feature is free for all users in the US and the UK: one person photographs a restaurant receipt, everyone else joins by QR code without the app, claims their own items, and gets a total with proportional tax and tip.
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.

Related guides

Why a receipt scanner should never let the AI do the math
Reading a receipt and computing the split are different jobs; three checks that catch a tool doing the wrong one.
Splitwise Free Limits: What You Get (and Don’t)
What changed in Splitwise’s free tier and when Pro makes sense.
The Mental Math Problem: Why We’re Bad at Splitting Bills
Why your brain can’t handle receipt math—and what cognitive science says about it.
The Science of Splitting Bills: Why Fair Splits Matter
The landmark research on why equal splitting makes groups spend more.

More in Practical Guides

All Guides

Sources

  1. 1 ICDAR2019 Competition on Scanned Receipt OCR and Information Extraction Zheng Huang, Kai Chen, Jianhua He, Xiang Bai, Dimosthenis Karatzas, Shijian Lu, C.V. Jawahar, International Conference on Document Analysis and Recognition, 2019
  2. 2 What We Know About Spreadsheet Errors Raymond R. Panko, Journal of Organizational and End User Computing, 1998
  3. 3 Spreadsheet Errors: What We Know. What We Think We Can Do Raymond R. Panko, 2008
  4. 4 The Inefficiency of Splitting the Bill Uri Gneezy, Ernan Haruvy, Hadas Yafe, The Economic Journal, 2004
  5. 5 Deep Learning Approach for Receipt Recognition Anh Duc Le, Dung Van Pham, Tuan Anh Nguyen, 2019
  6. 6 Multi-Modal Vision vs. Text-Based Parsing: Benchmarking LLM Strategies for Invoice Processing David Berghaus, Armin Berger, Lars Hillebrand, Kostadin Cvejoski, Rafet Sifa, 2025
  7. 7 CORD: A Consolidated Receipt Dataset for Post-OCR Parsing Seunghyun Park, Seung Shin, Bado Lee, Junyeop Lee, Jaeheung Surh, Minjoon Seo, Hwalsuk Lee, NeurIPS Document Intelligence Workshop, 2019

Order what you want.

Three free bills, then $9.99 a year, or $24.99 once.