bank API returned pending transactions mixed with posted: "balance mismatch" error

TL;DR

Pending transactions are promises, not movements: amounts change, some vanish, and the bank balance ignores them. If the API import treats pending as posted, the book side inflates and the rec cannot match the posted balance. Restrict the import to posted status, remove pending items already imported as if final, and keep pending in a forecast view only. Rebuild the rec from the last clean date using posted items exclusively.

bank API returned pending transactions mixed with posted: "balance mismatch" error

Use this when

• Imported transactions include items the bank still shows as pending.
• The mismatch amount equals the sum of pending items in the window.
• Some imported items later change amount or disappear at the bank.

Not for this skill when

• All imported items are posted and the mismatch persists. Work the rec difference directly.
• The bank balance itself includes pending in its available figure and your rec targets available balance by policy. Align the policy first.

Steps

1. Query the bank API response for the window and list each transaction with its pending or posted status flag. Verify: pending items in the import are enumerated with amounts
2. Total the pending items that were imported as final. Verify: their total explains the balance mismatch, in whole or in part
3. Remove or reverse the pending-as-final entries, keeping a record of them in a pending view with their bank ids. Verify: the GL no longer contains unposted bank promises as movements
4. Change the import filter to accept posted status only, and confirm the connector setting persists per account. Verify: a fresh pull returns zero pending items into the posting queue
5. When a pending item posts at the bank, confirm it now imports once with its final amount. Verify: no duplicate arises between the old pending record and the new posted record

Variant phrasings

bank API pending transactions imported as posted

The pending-leak phrasing.

pending transactions causing reconciliation mismatch

Searching by the mismatch cause.

Compatibility: Bank APIs including Plaid-style pending flags feeding QuickBooks, Xero, NetSuite, and custom ledgers.

Why it happens

Bank APIs expose pending transactions because apps want to show activity early, and the pending record carries an id that is often replaced when the item posts. Importers built for finality assume every returned row is a settled movement. Mixing the two breaks both amount accuracy, since pending card holds change, and identity, since the posted item arrives as a new row that naive dedupe treats as a second transaction.

Edge cases / pitfalls

• Card authorization holds are the worst offenders: fuel and hotel holds routinely differ from final amounts.
• Some banks expose pending only on certain account types. A connector change can start the leak without any user action.
• Keep the pending view for cash forecasting; the fix is excluding pending from posting, not from visibility.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstKMFetwAjyHfwm4ahkQ4OA