Dishcrepency

Delivery apps underpay restaurants inside lump-sum payouts. Dishcrepancy finds every mistake, proves it with the contract line, and files the dispute saving companies hundreds of thousands of dollars.

Comment

The problem

Noah's NY Bagels runs about 56 stores across California, and a good portion of their sales come through DoorDash, Uber Eats , Grubhub, along with their own app. Each of those companies pays Noah's on its own schedule, in its own format, under its own contract, and the rules are different everywhere you look.

  • DoorDash takes a flat cut that depends on which plan the store is on, somewhere between 15 and 30 percent.
  • Grubhub splits its charge into a marketing fee, a separate delivery fee and a processing fee on top.
  • Uber Eats charges one rate for a normal order and a higher one when the customer is an Uber One member. Then there are promotions, like a buy-one-get-one bagel deal where the app agrees to cover half the cost, and refunds, like a customer saying something was missing, which gets charged back to the store at the full price of the item plus tax.

All of this is taken out before the money arrives. What lands in the bank each week is one lump sum with a pile of subtractions hidden inside it, and someone on the finance team has to sit down and reconcile it against what the stores actually sold, against the bank, and against whatever deal was in force that week. If nobody does it properly, the money leaks. Operators who have looked at this closely put the loss at 2.5 to 3% of revenue, and dispute firms that fight these charges for a living win 80 to 90 percent of the time, which tells you how often the charges are gotten wrong in the first place. A real life example is La Patisserie, a family bakery in Cupertino. Their contract with DoorDash said 13 percent commission. DoorDash charged them 30 percent for eight years, and nobody noticed until the uncle who does the family's books spotted it. By then more than $100,000 had gone out the door, and it took a TV news story to get it back.

What Dishcrepency does

Dishcrepency takes that weekly job off the finance team's desk. It reads the statements, invoices and contracts from each delivery company, and it has connectors for the messier places the real information lives, like a Slack thread where someone agreed to a promo, an email from a DoorDash rep changing the rate, or a CSV someone downloaded from the merchant portal last Tuesday. It matches every order to what the app actually paid for it and checks each deduction against the deal that applied on that day. If a rep changed a rate by email last month, Dishcrepency has read that email, and it has also checked whether that rep was allowed to make the change.

Anything that does not add up becomes a finding, written the way an auditor would want to see it. It shows what was expected, what was paid, the gap in dollars, and the line in the contract or the email that proves it. Three agentic judges then look at each finding and vote/debate on whether the money can be recovered. When they agree, Dishcrepency drafts the dispute. When they disagree or something looks odd, Dishcrepency stops and passes it to a human in the loop with a short note on what it could not settle. Once a dispute is approved, Dishcrepency files it on the app's own website and writes the matching journal entry for the books.

What this is worth

Dishcrepency puts money back in the restaurant's pocket. La Patisserie's overcharge would have shown up in the first week, not the eighth year. Across an operation the size of Noah's, where 2.5 to 3 percent of delivery revenue is leaking and most of it can be won back, that is two to two and a half cents of every delivery dollar returned to the business, which for a chain doing around $22 million a year would work out to roughly half a million dollars a year saved.

It also gives back time. In our test, a full year of statements for 56 stores, around 1.24 million orders, was reconciled in about two minutes. At an hour per location per week, that same year is close to 3,000 hours of a person's time. The point is not necessarily that a script replaces the finance team. It is that the accountant gets freed up for the hard cases and the disputes worth fighting, while the volume keeps growing and nobody new has to be hired.

And it brings very valuable accountability. Every step Dishcrepency takes goes into an audit log that is immutable. It records what each agent did, what it found, who approved or rejected it and why. When an agent tries to skip the human, that attempt is written down too and marked as refused. Months later anyone can open any dollar on that list and see its whole history, with a name next to every decision.

Why a restaurant would pick us

Because, again, we put money back in the restaurant's pocket, and we only really get paid when they do. Dishcrepency charges a small flat fee for every transaction it processes, say 10 cents, and a significant fee, say 60 cents, only on a transaction where it actually recovered money. If nothing comes back, the restaurant pays almost nothing. That is a win for both sides, and it is a very easy conversation with a finance director.

Dishcrepency gets better on their own

Dishcrepency works on its own, and it also improves. When a person makes the same call a few times in a row, Dishcrepency proposes a rule in plain words, something like "DoorDash commission above the contract rate, almost always dispute". Once the person approves it, Dishcrepency handles those cases itself from then on. The judges also place a bet on every finding, and those bets are scored against what really happened, so a judge that is usually right earns more weight and one that is usually wrong earns less. Over months of human decisions and settled bets, Dishcrepency learns when it really needs to call a person and when it does not, and the aim is for that to happen as rarely as possible.

How we built it

Dishcrepency is a Python pipeline of twelve agents, a Slack and email connector, a LoRA-tuned Qwen2.5-7B judge served on an ASUS Ascent GX10, SpacetimeDB for shared state, and a gatekeeper that is the only thing allowed to file. Flock is the internal codename, which is why the repo and the database carry that name.

Ingestion and reconciliation. The Collector and Formatter organize sales records, platform statements, bank deposits, contracts, and supporting communications. The Matcher connects orders to payouts, while the Deal Keeper identifies the terms applicable on the transaction date. Deterministic checks verify the calculations, and the Anomaly Detector flags unusual deductions. The Investigator assembles unexplained differences into cases with expected amounts, actual payments, and supporting evidence.

Multi-agent judgment and the betting market. Three agentic judges examine each finding, debate competing explanations, and place confidence bets on whether the money is recoverable. Their bets are scored against observed outcomes, allowing consistently accurate judges to earn more influence. The Ranker prioritizes recoverable cases, and the Dispute Writer prepares the supporting argument. Disagreement or insufficient evidence triggers human review.

Local model training and inference. We LoRA-tuned Qwen2.5-7B-Instruct on judge cases generated by our own simulator and served it with Ollama on an ASUS Ascent GX10, air-gapped. On held-out seeds the tuned judge called 916 of 916 cases correctly with zero false alarms, against 910 for the untouched base model and 50.9% for CREAO's hosted agents on the same cases. Its output is never trusted on its own. Code computes every dollar figure, and the gatekeeper checks approval authority before anything is filed.

Controlled execution and auditability. Every state change goes through one gatekeeper function that checks who is acting, what they are allowed to do and what evidence backs it. Approved findings are filed by Clicky in the platform's portal, and every transition, including refused agent attempts, lands in an append-only audit log with the actor's name.

Learning over repeated runs. Approved corrections become scoped precedents. Repeated decisions can produce proposed rules that are tested against historical cases before approval. This works alongside the judge market to improve future decisions and reduce repeated investigations.

Live application state. SpacetimeDB holds findings, the audit log, agent status and transactions, so the console, the judge theater and the scoreboard all read the same record of what happened.

The main engineering challenge was keeping evidence, amounts, permissions, and case status consistent across these stages. We separated exact calculations from agent interpretation and made uncertainty an explicit reason to request human review.

Tracks

Hyphenate — Autonomous Systems for Finance

One finance workflow, carried end to end with a person deciding only when money moves. Dishcrepency reads statements, bank deposits, contracts and the Slack threads where reps change deals, checks every deduction in code, and turns each mismatch into a finding with the contract line that proves it. Three judge agents vote and bet their own balance, a human approves, the gatekeeper files, and the follow-up agent chases payment.

Measured on five simulated months for 56 stores: 1,945 of 1,945 planted mistakes caught, zero false alarms, hand-offs to a human down from 5 a month to 1 after three learned rules, and a year of statements reconciled in about two minutes. The audit log is append-only and records refused agent attempts under the agent's name.

Pricing is 10 cents per transaction processed and up to 60 cents only on a transaction where money was recovered, so we are paid when the restaurant is.

CREAO

Seven of Dishcrepency's agents run on CREAO: the reader that turns a rep's Slack message or email into a structured deal term, the three judges that vote on recoverability, the dispute writer, the follow-up writer, and the learner that words each proposed rule. The arithmetic stays in code, so the dollar figures are never a model's guess, and a human approves before the gatekeeper files. CREAO's share page lets a judge open a real run and read the agent's reasoning line by line.

Judge agent: Dishcrepency Judge Agent ID: 9f48f380-fcd8-44d3-8387-ab9f85cd1c50 Example run: https://agent.creao.ai/share/db6b2917902c5799ac9fee5906942a58

Microsoft — Built for the Real World

The customer is a real shape of business: a 56-store bagel chain selling through DoorDash, Uber Eats, Grubhub and its own app. The workflow is the one its finance team already does every week, reconciling each lump-sum deposit against sales, bank and contracts. Measured on five simulated months: a full year of statements reconciled in about two minutes against roughly 3,000 hours by hand, 1,945 of 1,945 planted mistakes caught with zero false alarms, and hand-offs to a human down from 5 a month to 1. Approvals, filings and refusals are logged under a named person or agent, which is what a finance director needs before letting software touch money.

Atlassian — Best Security Solution for Agents

Submitted to Atlassian Best Security Solution for Agents. The gatekeeper is the only path to money: agents can read, judge and draft, but only a signed-in human can approve and only the gatekeeper can file. Every attempt by an agent to skip that step is refused and written to the append-only audit log under the agent's name, so the record shows not just what happened but what was blocked.

Notability — Trust the Process

We used Notability Pro throughout development, from brainstorming and initial wireframes to architecture planning and judge feedback. On the dotted template, we combined handwriting, color-coded sections, imported diagrams, and annotations to work through agent responsibilities and human approval steps. Recorded discussions, timestamped transcripts, and Smart Notes helped us revisit explanations, while Action Items organized follow-up work. Our notebook documents how Dishcrepency developed, keeping early ideas, technical plans, and feedback together as we built.

SpacetimeDB

Dishcrepency's store layer writes findings, the audit log, agent status and transactions to a SpacetimeDB Maincloud database, and the console, the judge theater and the scoreboard all read the same tables. Only the gatekeeper writes a state transition, so the database is the audit trail rather than a copy of it. The module is written in Rust; the Python side talks to Maincloud over HTTP.

Public database: https://spacetimedb.com/@thabhelo/flock

Built With

Share this project:

Updates

Submission history