QuickBooks Reconciliation Discrepancy on a Stripe Account

Your March reconciliation was clean. You matched every payout, the difference read $0.00, and you moved on. Five months later QuickBooks opens the Reconcile screen with a warning that the beginning balance for that account is not what it was, and offers to help you fix it.

Nothing about today's numbers is wrong. Something about a month you already closed has changed, and QuickBooks has noticed. On a file where Stripe activity arrives through a sync, the account this happens to is almost always the same one: the holding account every synced record passes through.

This is a guide to that specific situation. It is not a reconciliation walkthrough. If you are setting the process up for the first time, how to reconcile Stripe to QuickBooks Online covers the two holding account patterns and the monthly routine, and the Stripe QuickBooks month end close checklist covers comparing the clearing account to the Stripe balance at a cutoff. Both of those are about the current period. This one starts after the reconciliation was already done and something moved underneath it.

If you would rather this class of problem stopped happening, Acodei syncs Stripe to QuickBooks with the record linkage that makes a broken period traceable in the first place. Start a free trial.

A beginning balance is just last month's ending balance

The alert is easy to misread because the word "beginning" suggests the start of something. It is really the end of the previous thing.

When you finish a reconciliation, QuickBooks stores that ending balance. The next reconciliation opens with it as the beginning balance. The two numbers are the same number wearing a different label, which is why the beginning balance can only change if the already-reconciled history behind it changed.

Intuit's guide to fixing beginning balance issues lists four ways that happens:

• "An incorrect opening balance entered when the account was created in QuickBooks."
• "A reconciled transaction was edited, deleted, voided, moved, or unreconciled."
• "A categorized bank feed transaction that was undone and sent back to 'pending'."
• "A transaction dated before your last reconciliation's ending date that was reconciled manually, adding it to your beginning balance outside of a reconciliation."

Intuit describes the mechanism in one sentence: "This changes the ending balance of your last reconciliation and sets the beginning balance for the next one."

Read the list again and notice what it does not contain. Nothing new arriving is on it. A charge that synced this morning cannot change March. Every cause is an edit to something that had already been reconciled, which narrows the investigation enormously before you have opened a single report.

Why it is nearly always the holding account

In a Stripe-fed QuickBooks file, one account carries more traffic than the rest of the chart of accounts combined.

The holding account is the account that stands in for your Stripe balance. Every synced sale is deposited into it, and every payout moves money out of it into the real bank account. That is its entire job, and it means that a business doing four hundred Stripe transactions a month has an account with four hundred synced records in it and a handful of payout entries, all of which someone might later have opened, edited, voided or deleted while tidying something unrelated.

Volume is only half of it. The other half is that holding account records look editable in a way that bank records do not. A bank line came from the bank and most bookkeepers will not touch it. A sales receipt sitting in a clearing account looks like something that was typed, so it gets treated like something that can be retyped.

That is the account the discrepancy report is usually pointing at, and it is the account to check first.

Opening the Reconciliation Discrepancy report

QuickBooks builds the report for you and hangs it off the alert.

Go to All apps, then Accounting, then Reconcile, and pick the account from the dropdown. If the beginning balance is off, the alert appears with a link reading "We can help you fix it". That link opens the report.

The column that does the work is What happened. It names the change for each row, rather than just listing suspects, so you are reading a set of events instead of a set of transactions. Selecting Review in tray on a row opens the transaction details next to the report, which is faster than opening each one in its own tab and losing your place.

Work the rows against your own records rather than accepting each suggestion. The report knows what changed. It does not know which version was correct, and on a synced file the answer is frequently that the original was correct and the edit was the mistake.

When you have resolved everything, the total discrepancy reads $0.00. That is the finish line and it is worth insisting on. A difference of eleven cents is not a rounding artifact you can carry forward. It is a transaction you have not found yet.

Narrowing it to a person, or ruling one out

The report tells you a record changed. It does not always tell you who changed it or why, and that is the question that decides what to do about it.

Intuit's own instruction is to use the audit log: go to Settings, then Audit log, filter to the account and the period since your last completed reconciliation, and review it for deleted or voided transactions.

On a file fed by a sync, that procedure gets considerably sharper because of how QuickBooks attributes automated writes. A connected application does not appear in the log as a user. It appears as a system profile. Intuit's audit log documentation states it directly:

"You connect a third-party app to QuickBooks. When the third-party app sends data to QuickBooks, or when it makes a change to your existing data, this appears as a System Administration event."

So the audit log for your holding account divides cleanly into two populations. One is System Administration entries, which is the sync doing its job. The other is named users, which is people. The list of people who touched a reconciled record in a given month is almost always short, and the answer is almost always in it.

Our QuickBooks audit log entry covers the rest of the object: the two year retention window, the difference between the file-wide log and the audit history on a single transaction, and the access rights each one needs.

The register check the report will not do for you

One of Intuit's four causes leaves no trace in the discrepancy report, because nothing was edited. A transaction dated before your last reconciliation's ending date can be marked reconciled by hand, directly in the register, which adds it to the beginning balance without any reconciliation having happened.

To find it: go to All Apps, then Accounting, then Chart of accounts, select View register on the account, filter by Reconcile status, and look for any transaction marked R dated after your last completed reconciliation.

An R that you did not put there is the whole answer. This usually comes from someone clicking the reconcile status field in the register to clear a stray line out of a view, not realising that the column is the reconciliation state rather than a display filter.

Five things that move a reconciled record in a synced file

This is where a Stripe file differs from an ordinary one. The generic advice assumes a human edited something. In a synced file there are more ways for a reconciled record to change, and some of them are legitimate operations that nobody would describe as an edit.

A resync rebuilt the record. Resync is Acodei's recovery mechanism, and the important detail for reconciliation is what it does mechanically: it deletes the QuickBooks side of a transaction and runs it through its sync job again, picking up any mapping or settings changes made since. For invoices specifically, a resync deletes and adds the invoice plus payment again. The rebuilt record is a new record. It is not the record you reconciled, and the reconciliation flag does not survive the round trip. If someone resynced a month to fix one broken row, every row they touched left the reconciliation with it.

Someone hand-edited a synced record instead of resyncing. This is the one with consequences beyond the reconciliation. Acodei's documented guidance is to resync from the Data Feed rather than manually altering transactions in QuickBooks, because manual edits break the linkage Acodei uses for reconciliation and reversal. A hand-edited record can therefore break twice: once by leaving the reconciliation, and again later when something that should have reversed it cannot find it.

A settings change was applied retroactively. Mapping, fee method and tax settings are never applied retroactively on their own. Changing them affects what syncs next, and nothing that already synced moves. Resync is what applies them to history, which means a settings change is quiet until someone resyncs, and then a batch of historical records changes at once. If your discrepancy dates cluster suspiciously, ask what changed in the settings, not what changed in March.

An invoice was renamed by hand. Acodei appends a suffix to synced invoice numbers by default, which is what prevents duplicate-number errors when a user also creates invoices directly in QuickBooks. The documented limit is worth knowing: automated suffixing does not protect against manual renaming of invoices in QuickBooks. Rename a synced invoice by hand and you have edited a reconciled record.

A bank feed transaction was undone. This is Intuit's third cause and it needs no sync to happen. Someone excluded or undid a categorized bank feed transaction, it went back to pending, and the reconciled state went with it.

Under Undeposited Funds, the question itself changes

Everything above assumes the reconciliation you are repairing was a balance reconciliation on a clearing account. Whether that is the right frame depends on a setup choice made long before the discrepancy appeared, and this is the part most reconciliation advice gets wrong for Stripe files.

With a non-UF asset account as the holding account, balance reconciliation is the correct method. The QuickBooks clearing balance should equal the Stripe balance, because every sale, fee and payout posts against the clearing account as it happens. The two can be compared daily, which is the gold standard, and monthly at minimum. Acodei has automated tracking built for exactly this and only for this mode: a daily tracker scoped to non-UF connections fetches the Stripe balance and the QuickBooks holding balance into per-day rows and records whether they match.

With Undeposited Funds, the appropriate method is narrower: match each payout deposit against the bank feed, then reconcile the bank account. Acodei does not support balance-reconciling the Undeposited Funds account itself, and the reason is timing rather than preference. Sales sit in UF until the payout deposit sweeps them, and some items, including deferred fees and mapped uncommon transaction types, are only added at deposit time. Those timing differences mean the UF balance can legitimately diverge from the Stripe balance at any given moment, so a point-in-time balance comparison is not meaningful the way it is for a clearing account.

The practical consequence for a discrepancy hunt is worth stating plainly. Under UF, your reconciliation checkpoint is the bank account and the payout deposits that land in it. A discrepancy alert on the bank account is a real signal and everything in this guide applies to it. Under non-UF, the clearing account is itself reconciled, so the alert can appear on the clearing account too, and it is meaningful there.

This is also the underlying reason non-UF is recommended for more complicated accounts. An asset clearing account can be balanced daily, so drift is caught within a day. Under UF, discrepancies inside the balance are invisible between payouts, and the only checkpoint is whether each payout landed correctly.

Switching between the two is a supported migration rather than a settings toggle. A dedicated job reverses and re-books the affected records, driven by a support command, which is not something to attempt in the middle of chasing a broken period.

Fixing it without creating the next one

Three rules keep the repair from becoming its own incident.

Void rather than delete. A deleted transaction is gone. Intuit is unambiguous: "Once a transaction is deleted in QuickBooks Online, it can't be restored." The audit log keeps the details so you can re-enter it by hand, and even that has a documented limit, since "Audit log only works for transactions that were saved." A voided transaction stays in the file, numbered and searchable, with its amount zeroed.

Rebuild through the sync, not by hand. If the record that broke came from Stripe, the repair path is a resync from the Data Feed, not a manual correction that makes the QuickBooks record look right. Manual corrections leave a record that matches Stripe visually while no longer being linked to it, which is the state that produces the next discrepancy. Our guide to reading Acodei Data Feed statuses covers what each status means before you act on one.

Leave closed periods closed until someone says otherwise. If the month in question sits behind a closing date, the fix is a conversation with whoever closed it, not a password prompt to be clicked through. A reopened period can invalidate filed returns, and a discrepancy of forty dollars is not worth that.

Work backward from the most recent complete month, and expect the answer to be one transaction. Reconciliation discrepancies are rarely diffuse. They are usually a single record that somebody opened for a good reason and saved for a bad one.

Frequently asked questions

What is a reconciliation discrepancy in QuickBooks?

It is a difference between the beginning balance QuickBooks expects for a reconciliation and the balance the already-reconciled history now produces. Because the beginning balance is stored from the previous reconciliation's ending balance, a discrepancy always means something in a period you already reconciled has been edited, deleted, voided, moved, unreconciled, or reconciled by hand outside a reconciliation.

Why does my Stripe clearing account keep showing reconciliation discrepancies?

Because it is the highest-traffic account in a Stripe-fed file and the one most likely to be edited after the fact. Every synced sale deposits into the holding account and every payout moves money out of it, so it holds far more records than any other account, and its records look hand-entered even when they are not. It is also the account most likely to be resynced, and a resync rebuilds records rather than editing them.

Does resyncing a transaction break my reconciliation?

For an already-reconciled transaction, yes. A resync deletes the QuickBooks side and books the transaction again through its sync job, so what you end up with is a new record rather than a modified one, and the reconciled flag does not carry over. This is expected behavior rather than a fault, but it means a bulk resync across a closed month will produce a discrepancy on that month. Resync deliberately and in the smallest scope that fixes the problem.

How do I tell whether the sync changed a record or a person did?

Use the audit log, filtered to the account and the period since your last completed reconciliation. Writes from a connected application appear under the System Administration profile rather than under a named user, because Intuit attributes third-party app activity that way. Entries under a real user name are the ones worth investigating.

Can I just adjust the difference to zero?

You can, and QuickBooks will let you, but the adjustment posts to an expense account and permanently hides the cause. On a synced file that cause is usually a specific broken record that will keep producing problems, including failing to reverse correctly if it is later refunded or disputed. Find the record. An adjustment is a last resort for genuinely unrecoverable history, not a shortcut past an afternoon of work.

What if the discrepancy is in a period my accountant has closed?

Do not reopen it yourself. Establish what changed and when, using the audit log and the discrepancy report, then take that to whoever closed the period. Reopening a closed period can invalidate filed returns, and the fix is frequently a current-period correction rather than a retroactive edit.

Stop hand-repairing periods that should not have broken

Most reconciliation discrepancies in a Stripe file trace back to the same root cause: somebody edited a synced record by hand because that was the only obvious way to fix it.

Acodei syncs Stripe charges, refunds, fees, payouts and invoices into QuickBooks Online with the record linkage that makes the alternative possible, so a broken record gets rebuilt through the sync instead of retyped. Sales receipts carry the original charge amount and the Stripe fee in the record's private note, duplicate protection numbers records so a re-sent webhook collides instead of duplicating, and the Data Feed shows what synced, what failed, and why. Start a free trial.