A pending bank transaction reappears as a posted transaction

A pending record and a posted record can describe the same underlying event. Inspect their account, status, references, dates and merchant details before deciding that the business paid twice. The final amount can differ from the initial authorization, so an exact amount match is helpful but not always available.

Plaid documents that a posted transaction may replace a pending transaction with a new identifier and that descriptions or amounts can change. Some pending authorizations disappear without posting. Those are characteristics of that data service, not a promise that every accounting integration handles the transition correctly. Confirm the behavior of the actual software in use.

Compare the final statement or posted activity with the underlying purchase, payment or refund. Determine whether there is one settled movement or two. A pending authorization may affect available funds while remaining different from a posted debit. Keep that distinction in the cash view without creating a second expense automatically.

For a business travel purchase, for example, an authorization and final charge can differ because the final bill changed. Verify the receipt and bank evidence rather than assuming that the larger amount is a duplicate. If two posted charges remain, investigate them as a possible duplicate through the merchant and bank.

Retain the relationship between the original and final records where the software exposes it. If references are unavailable, document the evidence used to match the event. Avoid removing a transaction solely because its date and merchant resemble another item. Repeated purchases at the same merchant can be valid separate transactions, especially for subscriptions or travel bookings.

Check whether the pending item was ever posted to the ledger or only displayed in a review queue. The correction differs. A display-only pending item may require no journal, while a duplicated ledger entry can affect expenses, payables or cash. Ask the accountant to review any entry already included in a closed period.

Inspect automatic rules and manual additions around the transition. A user may have created an expense from the pending item and then accepted another from the posted feed. Correct the duplicate through the software's supported process while retaining the source receipt and the final bank match.

If an integration repeatedly leaves both records active, preserve examples with timestamps and identifiers for support. The root issue may be lifecycle handling, not the bookkeeper's categorization. Repeated manual deletion can conceal the pattern and make future investigations harder.

Keep unresolved pending items separate from confirmed statement activity. Establish who follows up when an item remains pending unusually long or changes after it was recorded. The expected timing depends on the bank, merchant and payment type, so use the actual provider's guidance rather than a universal deadline.

At month-end, reconcile posted bank activity and document any accounting cutoff judgment for the underlying purchase. A purchase can have an accounting consequence before its bank settlement; the pending label alone does not determine the recognition policy.

Review the next statement for the final outcome and update the exception record. The completed trail should show the original authorization or instruction, the settled amount and any correction made, with one supported accounting treatment for the underlying event.