SquadPay
Splitting the bill is easy. Asking friends to pay you back is awkward.
The painful part isn’t the split. It’s the follow-up.
People forget who owes what, do arithmetic by hand, hesitate to ask friends for repayment, and send the same message twice. SquadPay is an AI-assisted shared-expense product — not primarily an AI product. AI is used only where it helps: reading a receipt. It never becomes the authority on the money.
Deterministic split core with AI ingestion
Gemini extracts merchant, items, quantities, prices, tax/charges and total. Everything downstream — schema validation, reconciliation, anomaly checks, the split math — is deterministic. Repayment goes out as a WhatsApp wa.me link, not native payment processing.
“AI extracts the receipt. Deterministic logic handles the money.”
“AI passed reconciliation and was still wrong.”
One Indonesian receipt produced extracted values roughly 1,000× too small: the model read a thousands separator as a decimal point. The numbers were internally consistent with each other, so SquadPay’s own reconciliation check passed. The values were still wrong. This was an AI extraction error, not a calculation error.
Lesson: Reconciliation can prove numbers agree with each other. It can’t prove they’re the right numbers.
A deterministic anomaly detector
A new check watches for unusual decimal precision, suspiciously low totals, and non-positive totals. It is not machine learning — an explainable, rule-based safety layer that flags output for review. It does not catch every incorrect receipt.
The warning appeared for the known scale-error case when tested. A later live edit exposed a second issue — the warning didn’t reliably reappear after a materially different edit, due to a dismissal-key bug. That was fixed and retested.
Evaluation on 15 real-world receipts
15 real, public/licensed receipts — 11 from ExpressExpense Sample Receipt Dataset, 1 from OCR.space public demo image, 3 from CORD. Ground truth created by hand and arithmetic-checked, not AI-generated.
| Run | Attempted | Parsed | Item | Qty | Price | Tax | Total | Complete | Reconciliation |
|---|---|---|---|---|---|---|---|---|---|
| Baseline | 15 | 11 | 84% | 100% | 91% | 73% | 91% | 33% (5/15) | 100% of parsed |
| Second run | 15 | 12 | 86% | 100% | 92% | 75% | 92% | 40% (6/15) | 100% of parsed |
11 ExpressExpense · 3 CORD · 1 OCR.space
Baseline parse rate (11 parsed / 4 failed)
Second-run parse rate (12 parsed / 3 failed)
Note: The second run followed system and error-handling changes, but its extractions matched the baseline except for one receipt: a rate-limit failure in the baseline that succeeded on rerun. That one-receipt gain is not evidence of better extraction. 100% reconciliation never equals 100% receipt accuracy.
Edge cases in raw receipt data
Multi-stage defensive architecture
No single layer is sufficient alone. No claim of zero hallucinations, 100% accuracy, or autonomous financial processing.
Field observation signals
Real-user testing surfaced several useful signals: participants described hesitation around asking friends for repayment, some needed a quick demonstration before understanding the product’s value, and several requested UPI/GPay integration for smoother payment completion.
Note: These observations may overlap, and the testing record doesn’t establish a verified total sample size — no combined count or percentage is reported.
Financial calculations stay deterministic · human review available · discount/coupon modeling deliberately deferred · no ML confidence model yet · UPI/GPay is future work · anonymous/demo states separated.
“Make settling up easier without making the user distrust the numbers.”
Not yet measured: time saved, retention, revenue.
Locale/currency not generalized · discount/coupon not fully modeled · reconciliation ≠ semantic correctness · anomaly detection not comprehensive · UPI/GPay not implemented · testing is directional only.