bank API returned pending transactions mixed with posted: balance mism

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

Deprecated endpoints keep answering but with reduced behaviour, and a silent 90-day window is a classic deprecation: the old endpoint serves recent data while the provider steers everyone to the new one. Check the provider's changelog for the deprecation notice and the replacement endpoint, migrate the agent's calls, and backfill the missing history from bank statements or the new endpoint's history range. Pin the API version in the client so the next deprecation announces itself as a version change instead of silent data loss.

agent called a deprecated transactions endpoint that failed to return history older than 90 days

Use this when

• History older than 90 days is missing while recent transactions arrive normally.
• The provider's docs mark the endpoint deprecated or describe a newer version.
• The agent's integration was built against an older API version and never migrated.

Not for this skill when

• The account or the API plan genuinely offers only 90 days of history. Then the data must come from statements, and no endpoint migration helps.
• All history including recent is missing. That is a broader auth or scope failure, not deprecation.

Steps

1. Confirm the deprecation: find the notice in the changelog and the recommended replacement endpoint and version. Verify: the migration target is stated by the provider, not guessed
2. Call the replacement endpoint for a test account and compare its history depth with the old endpoint's. Verify: the new endpoint returns the missing older history
3. Migrate the agent's transaction calls to the replacement endpoint with the API version pinned. Verify: the client declares its version explicitly
4. Backfill the missing history from the new endpoint or from bank statements, deduping on transaction id against the recent data already held. Verify: the combined history is continuous with no gap at the 90-day line
5. Reconcile the backfilled history totals per month against statements. Verify: each backfilled month ties to its statement

Variant phrasings

deprecated transactions endpoint 90 days history missing agent

The deprecation phrasing.

API version deprecated silent data loss migration

When pinning the version.

Compatibility: Versioned bank and accounting APIs with deprecated transaction endpoints.

Why it happens

Deprecation is a slow-motion breaking change. Providers keep old endpoints alive with degraded behaviour to avoid hard failures, and a degraded history window looks like a data problem rather than an integration problem, so teams debug their queries for weeks. The changelog is the source of truth, and version pinning converts future deprecations from silent degradation into explicit contract changes the team notices at upgrade time.

Edge cases / pitfalls

• Some providers gate history depth by plan tier on the new endpoint too; confirm the tier before assuming migration restores history.
• Deprecated endpoints can be removed with little notice after long deprecation; migrate on the notice, not on the removal deadline.
• Keep the old endpoint's data for overlap comparison during migration; it is the control set for the new endpoint's accuracy.

Provenance

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

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

Thread query: agent called a deprecated transactions endpoint that failed to return history older than 90 days

TL;DR: Deprecated endpoints keep answering but with reduced behaviour, and a silent 90-day window is a classic deprecation: the old endpoint serves recent data while the provider steers everyone to the new one. Check the provider's changelog for the deprecation notice and the replacement endpoint, migrate the agent's calls, and backfill the missing history from bank statements or the new endpoint's history range. Pin the API version in the client so the next deprecation announces itself as a version change instead of silent data loss.