WooCommerce Bank Reconciliation - Beta Review Workflow
Review WooCommerce orders, processor payout exports, payout status, mixed gateways, and bank deposits with a beta, review-heavy workflow.
Try with sample files | View sample report
Problem statement
WooCommerce stores often record gross order totals while the actual cash arrives through Stripe, PayPal, manual bank transfer, or another processor payout. WooCommerce support is beta and review-heavy: the safe workflow is usually orders to payout support to bank deposit, with weak gateway evidence left in review.
Numeric example
| Line item | Amount |
| WooCommerce gross orders | $2,410.00 |
| Refunds | -$180.00 |
| Processor payout deductions | -$84.80 |
| Bank deposit under review | $2,145.20 |
Why the numbers do not match
- A payout can be lower than gross orders because refunds, explicit processor fee rows, reserves, or adjustments reduce the net movement.
- Multiple orders are often combined into one processor payout or bank deposit.
- Orders placed today may not appear in the bank for several days because the processor payout lands later.
- Payout status can explain why expected cash is pending, delayed, failed, or otherwise not yet visible in the bank.
- Mixed payment methods can require separate support files before the bank row is explained safely.
- Manual bank transfer, cash on delivery, and other offline-payment orders can sit outside processor payout proof entirely.
- Order totals alone do not prove the payout composition or the final bank movement.
What files to export
- WooCommerce orders export with order number, date, total, payment method, status, refund fields, and customer reference.
- Payment gateway payout report with payout IDs, payout status, deductions, grouped batches, and net payout rows.
- Gateway status or settlement detail when held, pending, delayed, failed, or reserve-like payout states are not visible in the payout export alone.
- Bank statement CSV/XLSX with deposit date, amount, and raw bank description for the expected processor transfer.
Manual workflow
- Export WooCommerce orders for the reconciliation period.
- Export the matching processor payout report for the same period and payment method.
- Export the bank statement that covers the expected deposit dates.
- Separate orders by payment method and gateway before you start matching them to payouts or bank rows.
- Keep manual bank transfer, cash-on-delivery, and other offline-payment orders outside processor payout proof unless another export explicitly ties them to the bank movement.
- Check payout status before calling the case a true bank mismatch.
- Calculate expected payout support from gross orders, refunds, payout status, grouped batches, and any explicit payout deductions shown in the processor export.
- Match the expected payout to the bank entry by amount, date, and payout reference where available.
- Use amount-difference wording when the processor export shows a shortfall but does not fully prove whether it is a fee, reserve, timing effect, or adjustment.
- Keep unclear gateway splits, grouped payouts, and weak-reference rows in review instead of forcing a final answer.
Common mistakes
- Comparing WooCommerce gross order totals directly to one bank deposit.
- Skipping the processor payout export and trying to explain the bank row from orders alone.
- Mixing Stripe, PayPal, and offline-payment orders into one unsupported payout explanation.
- Using exact fee wording when the export only proves a broader amount difference or payout adjustment.
- Forcing grouped payout support into a final one-to-one bank match.
How Reconcile Locally helps
- Separates matched rows, amount differences, unknown bank payments, and grouped-payment review cases in one local workflow.
- Keeps order, payout, and bank support visible together instead of spreading the review across several spreadsheets.
- Keeps WooCommerce beta cases review-heavy when mixed gateways or weak references make the cash explanation incomplete.
- Exports a report you can hand off before changing accounting entries.
What still needs manual review
- Grouped payouts still need a reviewer decision when one bank row can plausibly match several order bundles.
- WooCommerce stores with several gateways may need one more export before the bank row can be explained safely.
- Some gateway plugins do not expose payout IDs or status cleanly, so one dashboard export or settlement view may still be required.
- Manual bank transfer, cash-on-delivery, or manually marked-paid orders should not be treated as processor payout proof without another supporting row.
- Keep amount-difference or payout-adjustment wording unless the processor export explicitly proves the exact cause of the shortfall.
Content review and sources
Written and reviewed by the Reconcile Locally product team. Last reviewed June 7, 2026.
Guidance is checked against current product behavior and first-party documentation where available. Reconciliation results still require human review.
Frequently asked questions
Why do my WooCommerce orders not match bank deposits?
Because the bank usually receives the processor payout, not the gross WooCommerce order total. Refunds, payout deductions, grouped deposits, timing gaps, and mixed gateways all change what reaches the bank.
Which export usually explains the shortfall best?
Usually the processor payout export. WooCommerce orders explain gross sales, but payout IDs, payout status, grouped batches, and deductions usually explain why the bank amount is lower or delayed.
Can I reconcile WooCommerce orders without connecting my bank?
Yes. Reconcile Locally works with exported CSV/XLSX files only. Download your WooCommerce orders and bank statement, then reconcile locally in your browser.
What if WooCommerce uses Stripe and PayPal at the same time?
Split the review by gateway first. Stripe and PayPal usually create separate payout support, timing, and deduction rows, so combining them before you review the payout evidence makes the bank explanation weaker.
Can I use the same workflow for manual bank transfer or cash on delivery orders?
Only partly. Those orders can still be reviewed against the bank, but they do not create the same processor payout proof as Stripe or PayPal. Keep them separate from gateway payout logic unless another export ties them in.