WooPayments 10.9 introduces beta Reconciliation Reports, including Balance and Fees reports. A multi-currency store can still produce misleading close work if order currency, transaction currency, settlement currency, conversion, fees, and payout bank currency are treated as one amount. The workaround is a controlled subledger by currency and payout, not an unlabelled spreadsheet conversion.
Use this for WooCommerce stores that price, charge, refund, or settle in more than one currency and need WooPayments data for bookkeeping, payout matching, tax review, or month-end close.
Quick answer
Export the WooPayments Balance and Fees reports for the same UTC period, keep every row in its original currency, split totals by currency, and map transactions to payout IDs before creating accounting entries. Record any settlement conversion as its own bridge line with the provider's rate and amount instead of silently converting the report total.
What to check first
- List every order, presentment, transaction, settlement, payout, and bank-account currency used during the period.
- Export Balance and Fees reports for the exact same UTC boundaries and preserve the untouched source files.
- Group charges, refunds, disputes, fees, and adjustments by native currency before summing anything.
- Join transaction IDs and payout IDs to the settlement statement and bank deposit.
- Create a documented conversion bridge for provider FX, bank FX, and accounting functional-currency entries.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
|---|
| Freeze the original Balance, Fees, payout, order, and bank exports for the period. | List every order, presentment, transaction, settlement, payout, and bank-account currency used during the period. | Every amount carries an explicit native or settlement currency and signed transaction type. |
| Normalize IDs and timestamps while retaining each native currency and signed amount. | Export Balance and Fees reports for the exact same UTC boundaries and preserve the untouched source files. | Balance and Fees exports use identical UTC period boundaries and are preserved unchanged. |
| Build one subtotal per currency and transaction type before any functional-currency conversion. | Group charges, refunds, disputes, fees, and adjustments by native currency before summing anything. | Payout IDs tie transaction groups to provider statements and bank deposits. |
| Join payouts and conversion lines to bank deposits using provider evidence. | Join transaction IDs and payout IDs to the settlement statement and bank deposit. | FX differences have a documented rate source, calculation, account, reviewer, and residual. |
Why this usually happens
- Store dashboards emphasize sales currency while payment and bank systems reconcile settlement currency.
- Spreadsheet imports can strip currency columns or coerce text amounts into one base currency.
- UTC report boundaries differ from local accounting dates near midnight and month end.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
transaction_id,order_id,type,native_currency,native_amount,fee,payout_id,settlement_currency,settlement_amount,utc_time
ch_101,8451,charge,EUR,120.00,3.90,po_501,USD,128.42,2026-08-07T22:14:00Z
re_202,8451,refund,EUR,-20.00,0.00,po_509,USD,-21.31,2026-08-09T01:10:00Z
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| Same-currency payout | USD charge settling to USD bank | Gross less fees and adjustments ties to payout |
| Converted settlement | EUR order settling to USD | EUR activity and USD settlement are joined by provider conversion evidence |
| Cross-period refund | Refund after original payout period | Refund remains in its event period and links to original transaction |
| Dispute lifecycle | Dispute opened and resolved in different periods | Each balance movement is retained with currency and payout context |
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Freeze the original Balance, Fees, payout, order, and bank exports for the period.
- Normalize IDs and timestamps while retaining each native currency and signed amount.
- Build one subtotal per currency and transaction type before any functional-currency conversion.
- Join payouts and conversion lines to bank deposits using provider evidence.
- Document residual differences, owner, materiality threshold, and closing decision.
Decision rule
A currency group is reconciled only when native activity ties to provider balance movements and the resulting settlement ties to a payout or documented open balance. Never force the difference into fees or FX without row-level evidence.
Production verification checklist
- Every amount carries an explicit native or settlement currency and signed transaction type.
- Balance and Fees exports use identical UTC period boundaries and are preserved unchanged.
- Payout IDs tie transaction groups to provider statements and bank deposits.
- FX differences have a documented rate source, calculation, account, reviewer, and residual.
Field notes
- Keep source exports immutable and perform transformations in a separate workbook or data table.
- Do not infer exchange rates from displayed order totals when the provider reports a settlement conversion.
- Use transaction and payout IDs as join keys; descriptions and customer names are not stable reconciliation keys.
Questions teams ask during testing
Can I use the order total as the settlement amount?
Not when conversion occurs. Use the provider's transaction and payout evidence for settlement currency.
Why keep UTC if accounting uses local time?
UTC preserves the report contract. Add a local accounting date as a separate field rather than changing the source timestamp.
Is the beta report enough for close?
Validate it against provider and bank evidence first, and document any known beta limitations for the period.
Mistakes to avoid
- Do not sum USD, EUR, GBP, or other currencies in one unlabeled total.
- Do not use local dates for one export and UTC dates for another.
- Do not overwrite native amounts with converted values.
- Do not classify an unexplained payout difference as processing fees.
What to tell the client or owner
Give finance the report version, UTC period, currencies, source file hashes, unmatched transaction count, payout differences, FX method, materiality threshold, and reviewer.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, reconcile WooPayments reporting.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Reconcile the WooCommerce 11.1 MOP and ZMW symbols
For stores using Macanese pataca or Zambian kwacha, run the WooCommerce 11.1 MOP and ZMW currency symbol test across checkout, gateways, orders, refunds, emails, PDFs, feeds, exports, analytics, and caches.
Helpful references