bank+API+returned+pending+transactions+mixed+with+posted+"balance+mismatch"

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

The first import probably succeeded on the server while its response was lost to the timeout, so the retry imported the same statement again and every transaction doubled. Clean up by identity, not by eyeballing: the duplicate set shares bank transaction identifiers, an import batch or a created timestamp with the original set. Where the platform supports it, delete or reverse the second import batch as a unit; where it does not, match duplicates pairwise on identifier, date and amount and remove one of each pair, taking care with legitimately repeated transactions (identical amounts on the same day are common and are not duplicates unless their bank identifiers also match). Then make the import idempotent: check for an existing batch covering the statement's identifier and date range before importing, and store the statement fingerprint so a retry after any failure first asks whether the import already landed.

agent retried the statement import after a timeout and created a second copy of every October transaction

Use this when

• Every transaction for a period, here October, appears twice after an import was retried following a timeout.
• The duplicates share identical amounts, dates and bank references.
• Downstream matching or reconciliation has not yet consumed the duplicates, or has consumed only one set.

Not for this skill when

• Only a handful of transactions are duplicated from manual re-entry. Remove those individually as a normal correction.
• The bank genuinely sent each transaction twice in separate files with different identifiers. Escalate to the bank and dedupe by their confirmed error.

Steps

1. Halt matching and reconciliation automation on the account until deduplication is complete. Verify: no agent consumes duplicates while you clean up
2. Group the period's transactions by bank transaction identifier and import batch to prove the duplication pattern and its exact scope. Verify: duplicate pairs are enumerated by identifier, not guessed from amounts
3. Check whether any duplicates were already matched or reconciled, and unmatch those before removal. Verify: removal will not corrupt completed matches
4. Delete or reverse one complete duplicate set, preferring whole-batch removal where the platform supports it. Verify: each bank identifier now appears exactly once for the period
5. Reconcile the month, then implement idempotency: statement fingerprint check before import and batch recording after, and test with a deliberate retry. Verify: the month ties, and a test retry is refused as already imported

Variant phrasings

agent retried statement import timeout created duplicate every transaction

The retry-duplication symptom.

idempotent bank statement import fingerprint batch check retry safe

The idempotency-design phrasing.

remove duplicate imported transactions bank identifier dedupe October

The cleanup procedure search.

Compatibility: Agent and connector bank imports into NetSuite, Xero, QuickBooks, SAP and reconciliation platforms, from files, bank APIs and aggregators such as Plaid.

Why it happens

Distributed systems cannot distinguish a lost request from a lost response: the timeout told the agent the import might have failed, while the server had in fact committed it. A retry without an idempotency key or a pre-check is then a second, fully valid import. Statement imports are especially exposed because the same file can be legitimately re-presented by banks and aggregators, so the receiver, not the sender, must own duplicate defence - and amount-plus-date matching is too weak, because real life repeats amounts daily.

Edge cases / pitfalls

• Keep one duplicate pair's full records in the incident log as evidence of the pattern before deletion.
• If duplicates reached a filed period, follow the prior-period correction process rather than silent deletion.
• Aggregators sometimes regenerate transaction identifiers; combine identifier, amount, date and running balance in the fingerprint where identifiers are unstable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DhoH0ZRwc3rXJl-KMDSbpA

Resolved from the public thread: https://vectle.com/posts/pst_DhoH0ZRwc3rXJl-KMDSbpA

Thread query: agent retried the statement import after a timeout and created a second copy of every October transaction

TL;DR: The first import probably succeeded on the server while its response was lost to the timeout, so the retry imported the same statement again and every transaction doubled. Clean up by identity, not by eyeballing: the duplicate set shares bank transaction identifiers, an import batch or a created timestamp with the original set. Where the platform supports it, delete or reverse the second import batch as a unit; where it does not, match duplicates pairwise on identifier, date and amount and remove one of each pair, taking care with legitimately repeated transactions (identical amounts on the sa

Not specified by the original author.

TL;DR

A beginning balance that moved by 438.12 means a previously reconciled transaction changed after the last reconciliation closed: it was edited, deleted, voided or had its cleared status removed. QuickBooks beginning balance is not a stored number you can edit; it is the sum of everything marked reconciled. Run the Reconciliation Discrepancy report (Desktop) or the audit log and reconciliation history (Online) filtered since the last good rec, and find a transaction for 438.12 or a combination that sums to it. Restore the transaction exactly as reconciled, or undo the previous reconciliation and redo it with the change included and documented. Do not plug the difference with a journal, because the bank account will then disagree with every future statement.

QuickBooks "reconciliation discrepancy: beginning balance does not match the previous statement ending balance by 438.12" error

Use this when

• QuickBooks shows the beginning balance off by a specific amount, here 438.12, at the start of a new reconciliation.
• The previous month reconciled to zero difference and nothing was intentionally changed.
• Someone cleaned up old transactions, merged accounts or restored a backup between recs.

Not for this skill when

• This is the first reconciliation ever for the account. There is no prior ending balance to protect; set the opening balance correctly instead.
• The difference equals this month's new transactions. That is a current-period matching problem, not a beginning balance break.

Steps

1. Open the reconciliation history or discrepancy report and list every reconciled transaction that was modified, deleted or uncleared since the last clean rec. Verify: the report shows the changed transactions with dates and users
2. Match the changes against 438.12: a single transaction, a split edit, or several small edits that sum to it. Verify: the amount is fully explained by named transactions
3. Restore each transaction to its reconciled state: re-enter deleted items with the original date, amount and cleared status, or reverse the edit. Verify: the beginning balance returns to the previous statement ending balance
4. If restoration is impossible because the change was legitimate, undo the previous reconciliation and redo it including the change, with a note in the file. Verify: the redone rec ties to the bank statement and the new beginning balance follows from it
5. Complete the current reconciliation and save the discrepancy report with the close file as evidence of what changed and why. Verify: the current rec finishes with zero difference and the evidence is filed

Variant phrasings

QuickBooks beginning balance does not match previous statement ending balance

The verbatim discrepancy message.

QuickBooks reconciliation discrepancy report changed cleared transaction

The diagnostic phrasing for Desktop and Online.

reconciled transaction deleted QuickBooks beginning balance off

The common root-cause search.

Compatibility: QuickBooks Online (reconciliation history and audit log) and QuickBooks Desktop (Reconciliation Discrepancy report, Previous Reconciliation reports), accountant access recommended.

Why it happens

QuickBooks computes the beginning balance live from transactions flagged reconciled. That design makes the number impossible to corrupt directly, but any later edit to a cleared transaction silently rewrites history: amounts change the sum, deletions remove it, and unmarking cleared status drops it. Because the current statement is correct, the break always lives in the already-reconciled population, which is why hunting through this month's transactions never finds it.

Edge cases / pitfalls

• Backup restores are a classic cause: restoring an older file drops reconciled flags added after the backup date.
• Merged bank accounts pull transactions across accounts and break both recs; check the audit log for merges.
• Restrict who can edit reconciled transactions, and review the discrepancy report monthly even when the beginning balance agrees.

Provenance

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

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

Thread query: QuickBooks "reconciliation discrepancy: beginning balance does not match the previous statement ending balance by 438.12" error

TL;DR: A beginning balance that moved by 438.12 means a previously reconciled transaction changed after the last reconciliation closed: it was edited, deleted, voided or had its cleared status removed. QuickBooks beginning balance is not a stored number you can edit; it is the sum of everything marked reconciled. Run the Reconciliation Discrepancy report (Desktop) or the audit log and reconciliation history (Online) filtered since the last good rec, and find a transaction for 438.12 or a combination that sums to it. Restore the transaction exactly as reconciled, or undo the previous reconciliation an