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.

By Zuny Fester, Head of Operations and Marketing

Reviewed by Zuny Fester

Published September 14, 2026Last reviewed September 14, 2026Editorial policy

Part of the finance integrations guide.

Symptom	A transaction is missing from, or duplicated in, a closed period's reconciliation
Root cause	A pending transaction at period-end settles later, with its own date field distinct from when it was pulled
Two relevant date fields	date (posted date once settled) and authorized_date (when it was authorized, which can differ)
Pending flag	The pending boolean marks a transaction whose details may still change before settlement
Where this shows up	A transaction present in one sync as pending, absent from the next as removed, replaced by a posted transaction with a new transaction_id

Why a period-end snapshot can be wrong the moment it's taken

Plaid's transaction data distinguishes a pending transaction — one whose details, per Plaid's own documentation, "may change before they are settled" — from a posted one. A pending transaction taken at face value on the last day of a period isn't wrong exactly, but it isn't final either: its amount, category, or existence itself can still change. A close process that treats a pull at 11:59pm on the last day as the definitive record of the period is treating a snapshot of in-flight data as if it were settled fact.

Two ways this actually breaks a close

First: a transaction that was pending at period-end and later removed (because it settled under a new transaction_id, per the sync model's added/modified/removed pattern) can end up missing from the closed period entirely if nothing re-checks it after the fact — the close moves on, and the settled version never gets pulled back into the record it actually belongs to. Second, the opposite failure: the same transaction gets picked up again in the next period's data (now posted, with its own date) and counted there too, double-counting activity that logically belongs to the period it was authorized in, not the period it happened to settle in.

What to actually check before locking a period

Filter on the pending status explicitly, and decide deliberately which date governs period assignment — authorized_date (when the activity actually happened) or date (when it posted, which for a pending transaction is initially the same as authorized_date but updates once it settles). Whichever is chosen, apply it consistently, and re-check any transaction that was pending at the moment of the close snapshot after it has had time to settle, rather than assuming a pending transaction's absence from the next pull means it resolved itself correctly.

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.

Book a workflow review

Worked example

A pending charge on the 31st that settles on the 2nd with a different transaction_id

A $3,100 card transaction is authorized on the 31st, the last day of the month, and shows up in that day's Plaid pull as pending, transaction_id txn_pend_501, authorized_date the 31st. The close snapshot is taken that night and includes it as pending activity for the period. Two days later, on the 2nd, the transaction settles: Plaid's next sync returns txn_pend_501 in removed and a new transaction, txn_post_902, in added — posted, date the 2nd. If nothing goes back to check what happened to txn_pend_501, the close record still shows a pending $3,100 transaction that no longer exists in Plaid's feed, and the settled version sitting in the following period's pull looks like new activity for that period instead of the tail end of the prior one.

Frequently Asked Questions

There's no single universally correct answer — it depends on whether the close process is meant to reflect economic activity (authorized_date) or actual bank posting (date). What matters is picking one deliberately and applying it consistently, rather than letting it default to whichever field happened to be read first.

Long enough for typical settlement times at the institutions involved — a few business days is common, but this varies by bank and transaction type; the safer practice is to re-run a check for any transaction still flagged pending at the original snapshot, rather than assuming a fixed window covers every case.

Any transaction type Plaid can mark pending is subject to this, though pending windows and the reasons for a status change vary by transaction type and institution.

Sources

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.

Topic

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…

Diagnostic

What breaks when a reconciled Plaid transaction changes to modified or removed?

Plaid transaction data isn't immutable. A pending transaction can be removed from the feed entirely and replaced by a different transaction once it posts, and a bank can remove a transaction outright. If a payment was already matched to the old transaction, that match is orphaned the moment the removal comes through, and the replacement has to be found and re-matched — it doesn't update in place.

How-to

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.