She later warned that a "full reconciliation to the last dollar with the Synapse ledger" might not be possible. Hiring an outside firm to finish the job would have cost $2 million to $3 million, and the estate didn't have it. A later report said the exact amounts and sources of the shortfall had not been clearly established.

I'm an accountant who also builds software. From the accounting side, that is a failed reconciliation, one of the oldest tests in the profession. Auditors have a short list of tests like it. If you write code that touches money, you can run every one of them yourself, and most take fewer than ten lines.

So I wrote them. Each test below is a query or a few lines of Python. I built a small ledger with one planted error per test and confirmed that every test catches its error. I also ran the numbers on how often the common shortcuts go wrong.

What does an auditor actually check?

An auditor doesn't read every transaction. There are too many. They test a handful of claims the books are making, called assertions. For transactions, the main ones are:

• Occurrence. What's recorded really happened.
• Completeness. Everything that happened is recorded.
• Accuracy. The amounts are right.
• Cutoff. It's recorded in the right period.

The U.S. standards for private-company audits and the international standards use the same list. The board that oversees public-company audits groups them a little differently, with the same goal.

Think of a home inspector. He doesn't rebuild the house. He checks the roof, the wiring, the plumbing and the foundation, because that's where houses fail. These four are where books fail.

Test 1: Can you recalculate it?

Assertion: accuracy.

The first thing an auditor does with a number is recompute it. Try that in Python:

>>> 0.1 + 0.2
0.30000000000000004
>>> int(0.29 * 100)
28
>>> round(1.005, 2)
1.0

A 29-cent charge just became 28 cents. Computers store numbers like 0.29 in binary, and most decimals don't fit exactly, the same way 1/3 doesn't fit in decimal.

How often does it bite? I tested every price from $0.01 to $100.00. Converting dollars to cents with int(price * 100) gave the wrong answer for 573 of the 10,000 prices. Then I took 10,000 amounts that end in half a cent ($0.005, $0.015, up to $99.995) and rounded them with Python's built-in round(). It disagreed with the round-half-up rule from school on exactly 5,000 of them. A coin flip.

Each bar is 10,000 test amounts.

Payment companies solved this long ago. Stripe's API takes amounts as whole numbers in the currency's smallest unit, so $10.00 is 1000 and ¥10 is 10. Store cents as integers. When you have to round, say how:

from decimal import Decimal, ROUND_HALF_UP

def to_cents(text):
    amount = Decimal(text).quantize(Decimal("0.01"), rounding=ROUND_HALF_UP)
    return int(amount * 100)

def allocate(total_cents, parts):
    base, extra = divmod(total_cents, parts)
    return [base + (1 if i < extra else 0) for i in range(parts)]

to_cents("1.005")     # 101
allocate(10000, 3)    # [3334, 3333, 3333]

allocate matters because $100.00 split three ways is $33.33 three times, which is $99.99. Somebody has to get the extra penny, and your code should decide who.

Rounding has one more trap, which is where you do it. Sales tax can be rounded on each line of an invoice or once on the invoice total. Both are legitimate. Stripe supports both, and the tax software company Sovos notes that different states require different methods. They just don't give the same answer.

I simulated 10,000 invoices with one to eight line items each, taxed at 7%, the combined rate in Broward County, Florida. The two methods disagreed on 3,769 invoices. That is 43% of the invoices with more than one line.

Simulated invoices with random prices from $0.99 to $199.99 and a fixed seed, so the run can be repeated.

Here's the part an accountant notices. Across all 10,000 invoices, the two methods landed $1.12 apart on about $315,000 of tax. An auditor would call that immaterial and move on. But the differences run in both directions and cancel out. Add them up without the plus and minus signs and it's $39.92, spread across 3,769 invoices. Each one is a customer whose receipt doesn't match your tax report.

Totals that look fine can hide thousands of rows that don't tie. So test the rows:

SELECT i.invoice_no, i.total_cents, SUM(l.amount_cents) AS lines_cents
FROM invoices i JOIN invoice_lines l ON l.invoice_no = i.invoice_no
GROUP BY i.invoice_no, i.total_cents
HAVING SUM(l.amount_cents) <> i.total_cents;

Test 2: Does the ledger foot?

Assertion: accuracy, one level up.

"Footing" is accountant for adding up a column and checking the total. In double-entry bookkeeping every transaction has two sides, and they have to net to zero. Money that leaves one account must arrive in another. If you store debits as positive numbers and credits as negative, the test is one query:

SELECT txn_id, SUM(amount_cents) AS out_of_balance
FROM journal_lines
GROUP BY txn_id
HAVING SUM(amount_cents) <> 0;

Any row that comes back is money your code created or destroyed. In my test ledger I planted a transaction that was off by one cent. It came back.

Test 3: Does it match the outside world?

Assertions: occurrence and completeness.

This is the test at the center of the Synapse story. Your database is your opinion about the money. The bank or the payment processor has the facts. A reconciliation compares the two, and it has to run in both directions:

SELECT 'in our books, not at the processor' AS problem, p.processor_id
FROM payments p
LEFT JOIN processor_report r ON r.processor_id = p.processor_id
WHERE r.processor_id IS NULL
UNION ALL
SELECT 'at the processor, not in our books', r.processor_id
FROM processor_report r
LEFT JOIN payments p ON p.processor_id = r.processor_id
WHERE p.processor_id IS NULL
UNION ALL
SELECT 'amounts disagree', p.processor_id
FROM payments p
JOIN processor_report r ON r.processor_id = p.processor_id
WHERE p.amount_cents <> r.amount_cents;

The first block tests occurrence: we recorded a payment that never happened. The second tests completeness: a payment happened and we never recorded it.

It's easy to write the first check and skip the second, and the second is the harder one. You can't find a missing row by searching the table it's missing from. The evidence has to come from outside.

Test 4: Is it in the right period?

Assertion: cutoff.

from datetime import datetime
from zoneinfo import ZoneInfo

sale = datetime(2026, 12, 31, 21, 30, tzinfo=ZoneInfo("America/New_York"))
print(sale.date())                               # 2026-12-31
print(sale.astimezone(ZoneInfo("UTC")).date())   # 2027-01-01

A sale at 9:30 on New Year's Eve in Miami is a 2026 sale to the owner and a 2027 sale to a server that keeps time in UTC. On the East Coast in winter, that's true for every sale from 7 p.m. on. In summer it's every sale from 8 p.m. on.

Auditors test this by pulling the transactions just before and just after the end of the period, because that's where revenue slides into the wrong year. Stripe's financial reports can be run in your account's time zone or in UTC, and its reporting API uses UTC unless you tell it otherwise. If your app says December and the export says January, Test 3 will light up with differences that are really Test 4 problems.

The fix is a decision. Pick one time zone for the books, write it down, and convert at the edges. Then write a test with one sale at 11:59 p.m. and another at 12:01 a.m., and check that each lands where you said it would.

Test 5: Is anything missing, or recorded twice?

Assertions: completeness and occurrence, from another angle.

Check numbering is one of the oldest controls in bookkeeping. If check 1004 is missing between 1003 and 1005, somebody has to explain where it went. Invoice numbers work the same way:

SELECT prev_no + 1 AS first_missing, invoice_no - 1 AS last_missing
FROM (SELECT invoice_no,
             LAG(invoice_no) OVER (ORDER BY invoice_no) AS prev_no
      FROM invoices) t
WHERE invoice_no - prev_no > 1;

Duplicates are the mirror image:

SELECT processor_id, COUNT(*) AS times_recorded
FROM payments
GROUP BY processor_id
HAVING COUNT(*) > 1;

Developers already know one version of this control. It's called an idempotency key: you attach a unique ID to a request so that a retry doesn't charge the customer twice. Stripe supports them, but its documentation says it keeps keys for at least 24 hours and can remove them after that. So the processor's protection has an expiration date. The permanent one is a unique constraint in your own database, and the query above is how you prove it's working.

One habit goes with this test. Never edit or delete a posted entry. Accountants fix a mistake by posting a second entry that reverses the first, so the mistake and the correction both stay visible. To anyone reviewing the books later, a gap or an edited row looks the same as fraud.

All five ran against a small test ledger with one planted error each. All five errors were caught.

So what should you do with this?

Here is where developers have an edge over auditors. An auditor samples. They pull a few dozen transactions out of a million, because checking every one by hand is impossible. You don't have that limit. All five tests can run against every row, every night, and page someone when a row comes back.

That's what I take from Synapse. Reconciling after the fact was priced at $2 million to $3 million and still wasn't expected to reach the last dollar. Reconciling every night is a scheduled query.

If you only have an hour, start with Test 3, because it's the one that tells you whether the money is really there. Then do Test 1, because it's the most common bug. It keeps turning up in public bug trackers: this week one open-source billing project fixed a statement that printed totals one rupee low, and another project's tracker documents $1.005 turning into 100 cents. The other three are cheap insurance.

Figures come from a script I wrote and ran on Nov. 12, 2026 (Python 3.10, SQLite 3.37). All test data is generated by the script and nothing was downloaded. This is general information, not accounting, tax or legal advice for your situation. Written by Brandon Robert Rodriguez.

Sources

• Synapse Chapter 11 trustee's status report, July 16, 2024 (shortfall estimate of $65 million to $96 million between partner-bank cash and the Synapse trial balance)
• NBC New York / CNBC, "Nearly $109 million in deposits held for fintech Yotta's customers vanished in Synapse collapse, bank says" (trustee on reconciliation "to the last dollar")
• Axios, "Synapse debacle cost some users their life savings," Nov. 25, 2024 (outside reconciliation estimated at $2 million to $3 million)
• PYMNTS, "Synapse Bankruptcy Trustee Seeks Chapter 7 or Dismissal" (sources of the shortfall not clearly established)
• Thomson Reuters, "Audit assertions explained: Types, risks, and best practices"
• Fieldguide, on why the completeness assertion is the hardest to test
• Stripe Docs, Supported currencies (amounts in the currency's minor unit)
• Stripe Docs, Tax rates (line item level and invoice level rounding)
• Sovos, "How does Global Tax Determination handle rounding?"
• Avalara, Broward County, Florida sales tax rate (7% combined for 2026)
• Stripe Docs, Advanced error handling (idempotency keys retained for at least 24 hours)
• Stripe Docs, Scheduled reports (account time zone or UTC)
• Stripe Docs, How the Reports API works (timezone parameter defaults to UTC)
• Python documentation, round() and the decimal module
• GitHub issue, "ledger statement and Day Book PDFs can show totals ₹1 less than the real amount," opened and fixed Nov. 10, 2026
• GitHub issue, "Dollar-to-cents conversion can silently lose a cent due to float rounding"