Bank-feed data vs. payment-processor data: why accounting needs both

The bank feed shows activity in the connected bank account. A payment-processor export explains activity inside the payment service, such as customer charges, refunds, fees, and payouts. The two records overlap at the deposit, but they are not interchangeable. An accounting integration should preserve the explanation of the money as well as its arrival.

This distinction matters when choosing a bookkeeper or a connector. Ask whether the proposed work includes reconciling the processor's balance and transaction detail, or only categorizing deposits from the bank. Both can be described loosely as payment reconciliation, even though they leave the business with different records.

IRS recordkeeping guidance explains that business records need to support reported income and expenses. A bank connection can contribute to those records, but it does not automatically supply the invoices, transaction detail, or other supporting evidence relevant to every entry.

Consider an illustrative payout containing $1,000 in customer charges, $100 in refunds, and $30 in processing fees, with no other adjustments. The resulting deposit is $870. Coding that deposit as $870 of sales loses the separate explanation of the customer activity and the processing cost. Your accountant should determine the actual posting under your accounting policy.

In a separate version of the example, suppose the provider retains $70 of the $870 until a later payout. Only $800 reaches the bank, while $70 remains with the processor. The bank feed cannot by itself explain that retained balance; the provider's records are needed. A month-end difference may reflect timing, a fee, a refund, or missing data and should be investigated before being labeled an error.

Duplicate entries are a common design risk when several tools connect to the ledger. If the ecommerce connector posts sales and the bank rule also creates sales from the deposit, the same activity may be recorded twice. Decide which system supplies each type of entry and what the other connections are expected to match.

A2X's Shopify documentation describes importing payouts and sales into accounting and distinguishing the handling of Shopify Payments from other gateways. That is one example of a settlement-aware integration. It does not establish that any particular setup will be correct without reviewing the mappings and other active connections.

Request a diagram or short written map of the active connections. Include the store, payment providers, accounting app, bank feeds, and any manual month-end entries. Mark which creates records, which only supplies evidence, and which can change an existing entry. This makes accidental overlap easier to see before launch.

Select a payout that spans the end of a month and ask how the integration assigns activity to periods. A payout date, a transaction date, and the date the bank posts a deposit may differ. Your accounting policy and the underlying evidence should drive the treatment, rather than an undocumented default in the connector.

Then test a refund issued in the following month and a fee adjusted after the original report was imported. Ask how the revised information reaches the ledger, whether an already closed period can be changed, and who reviews the exception. The answer should include a clear process for corrections.

Avoid forcing the clearing balance to zero simply to finish the close. Keep an explanation of legitimate unsettled amounts and investigate unsupported differences. The reviewer needs to know what remains open, why it remains open, and which later report or deposit should resolve it.

Connected bank data can change as transactions move through their lifecycle. Plaid's documentation explains that a pending transaction may be removed and a posted transaction added with a different identifier; other details may change too. A data connection therefore needs a defined way to handle updates, rather than treating every imported row as permanently final.

Ask the integration vendor how it prevents duplicate imports and how it represents corrections. For processor data, require stable references connecting the order, payment, refund, payout, and bank entry where those references are available. Keep the original export alongside any accounting summary so that a reviewer can trace the result.

Use anonymized records from a representative period. Include a normal payout, a partial refund, a disputed payment, a fee, and a month-end balance. Ask the vendor or service provider to explain the required configuration and the work a person still performs. A clean example with only successful sales will hide the difficult parts.

Require the output to include the proposed accounting entries, the match to the bank, an explanation of the remaining balance, and a list of unresolved items. Measure how long the reviewer needs to understand the result. Automation that produces a complicated exception queue may move work rather than remove it.

Stripe's payout-reconciliation report matches automatic payouts to transaction batches. Its documentation describes a different reporting route for manual payouts and says Instant Payouts must be reconciled against transaction history. Confirm the report for your account configuration and obtain equivalent evidence for every other provider involved.

Choose the connection and service scope that let finance explain sales activity, payment costs, unsettled balances, and deposits without guessing. Keep the bank feed, but make sure the payment detail it cannot contain is supplied through another reliable route.

Put the responsibilities into the onboarding plan: who reviews mappings, who handles failed imports, who reconciles each provider balance, and who approves corrections. The finished workflow should remain understandable when a new bookkeeper takes over or a different payment provider is added.