How do I reconcile a period-end Plaid balance against the live account balance?
Take a single /accounts/balance/get call at a fixed cutoff and record both the current and available balance it returns — current ignores pending transactions, available nets them out. Use current for a clean period-end snapshot, since it won't keep shifting as pending items settle, and treat any later call's different balance as expected drift, not an error to chase.
By Zuny Fester, Head of Operations and MarketingPart of the finance integrations guide.
| current balance | Does not take pending transactions into account |
|---|---|
| available balance | Predicted balance net of pending transactions |
| Data completeness | current balance has a higher fill rate from institutions than available balance |
| Why they can differ | Any pending transaction at the moment of the call widens the gap between the two |
| What changes after the snapshot | Both figures can move as new transactions post — a live balance is a moving target by design |
Why "the balance" is actually two numbers
Plaid's /accounts/balance/get endpoint returns both a current and an available balance, and they answer different questions. Current balance doesn't take pending transactions into account — it reflects only what has actually posted. Available balance is, in Plaid's own words, a predicted balance net of any pending transactions — its best estimate of what the account will settle to once everything in flight clears. For a period-end reconciliation, that distinction is the whole ballgame: current balance is stable once you've pulled it, because posted transactions don't get un-posted; available balance keeps moving as pending items settle, which makes it a poor choice for a number meant to represent a fixed point in time.
Why comparing snapshot-to-live looks like a discrepancy that isn't one
If a period-end snapshot recorded current balance as $84,200 on the last day of the month, and a later call — even a day later — returns $85,650, that's not necessarily an error in either number. New transactions posted in the intervening time, which is exactly what a live balance is supposed to reflect. The mistake is treating the snapshot as if it should still match the live account: it was correct for the moment it was taken, and the account has simply moved on since then, the same way any bank balance does.
How to do the reconciliation correctly
Record the current balance (not available) at a fixed, defined cutoff — the same moment every close should use, not "whenever someone happened to pull it." Reconcile that number against the accounting system's own book balance for the same date, not against whatever the live Plaid balance shows when someone checks weeks later. If the two don't match at the snapshot date, investigate transactions dated on or before the cutoff that hadn't posted yet — that's a real reconciling item. A difference between the recorded snapshot and today's live balance, on its own, isn't one.
Next step
Map the finance workflow with the most exposure and prove the automation path.
Bring the invoice, contract, payment reconciliation, or customer finance workflow you have to defend at audit. Loopfour can map the trigger, controls, integrations, and approval loop.
Worked example
Why a $1,450 'gap' three days after close isn't a reconciliation failure
Close snapshot on the 31st records current balance $84,200 via /accounts/balance/get, matching the books for that date exactly. Three days later, someone spot-checks the account and sees a live current balance of $85,650 — a $1,450 gap from the recorded close number — and flags it as unreconciled. It isn't: three transactions totaling $1,450 posted on the 1st and 2nd, after the close cutoff. The $84,200 figure was correct for the 31st and was never supposed to still match the account today. The actual check that matters is whether $84,200 matched the books as of the 31st, which it did — not whether today's live number still equals a number recorded three days ago.
Frequently Asked Questions
Sources
Related
Diagnostic
When do Excel consolidations become too risky for month-end close?
Risk crosses from unlikely to expected once two or more are true: 4+ legal entities consolidated, 2+ reporting currencies, 3+ people editing the close workbook, or 50+ manual journal entries per close. Below those, a well-built workbook is usually manageable; above them, nothing stops a broken formula from producing a confident, wrong number.
Read moreTopic
Integrations
Every finance automation vendor publishes an integrations page: a grid of logos, a claim of "seamless" connectivity, and not much else. That page answers a marketing question — does this vendor touch…
Read moreHow-to
How do I set up Plaid /transactions/sync for bank feed reconciliation?
Call /transactions/sync with a null cursor the first time for an Item, store the next_cursor it returns, and pass that cursor back on every later call to fetch only what changed. Loop while has_more is true, and process the added, modified, and removed arrays as three distinct kinds of change — not as one undifferentiated transaction list.
Read moreDiagnostic
What breaks when pending Plaid transactions post after month-end lock?
A transaction Plaid shows as pending on the last day of the month can settle days later with a posted date that still falls before close. If a snapshot is taken while it's pending and never revisited, that transaction can be missing from the close entirely, or double-counted if it's picked up again next period without checking whether it was already included.
Read more