Why your ecommerce connector may have doubled sales

A common duplication pattern is an order or settlement connector posting revenue while the bank feed categorizes the resulting payout as new sales. Another is a migration running the old and new connectors over the same dates. Trace the source of each entry before changing the totals.

Pick a small period with a known order count. Export the sales entries with source names, external references, amounts, and dates. Matching amounts are a clue, not proof: two legitimate orders can have the same value. Use order, batch, invoice, and payout identifiers wherever possible.

Document who records gross sales, discounts, refunds, fees, taxes, and transfers to the bank. A connector can own the sales summary while the bank feed matches the payout against a clearing account. Two systems can contribute to the same reconciliation without both creating revenue.

In an illustrative case, the connector records $10,000 of sales and the bank receives a $9,700 payout after $300 of fees. Categorizing the bank deposit as sales creates $19,700 of recorded revenue for the same activity. The correction must preserve the genuine $10,000 sale and $300 fee as well as the bank movement.

Pause the overlapping posting path through an approved change while leaving necessary payment processing intact. Save the current mappings, synchronization dates, and exports. Do not disable a production payment integration merely because its accounting export is duplicated.

Have the accountant approve the affected periods and correction method. Closed or filed periods may require additional review. Keep a record of removed or reversed entries and their original references so the repair can be understood later.

Reconcile the repaired sales population to the store report, the processor clearing account to settlement detail, and the bank to its statement. Check a refund and a payout crossing month-end, not only an ordinary completed order. These cases often reveal a mapping that still uses the wrong date or account.

After the next synchronization, confirm that historical entries were not recreated. Set a cutover boundary and retain stable external identifiers in the integration. Monitor source-level counts and totals for the first subsequent close, with one owner responsible for investigating any repeated batch.