WooPayments Reconciliation Reports Land in 10.9 Beta

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

Every WooCommerce store that takes cards has the same monthly ritual. Someone in finance opens the bank statement, someone else opens WooCommerce Orders, a third tab opens the payment gateway dashboard, and the next two hours are spent proving that the three numbers agree. On a good month you find nothing. On a bad month you find a currency-conversion rounding gap, a disputed charge that never came back, a refund that hit the gateway but not the order, and a payout that mixed two weeks of activity into one line.

I have watched clients build entire internal tools around that ritual. Google Sheets with VLOOKUPs against exported CSVs. Custom mu-plugins that pull Stripe balance transactions and match them to Woo orders by metadata. One agency I know keeps a Retool dashboard alive just for this. All of it exists because the answer to “how did my WooPayments balance get from the start of the month to the end of the month” was, until now, a spreadsheet.

WooPayments 10.9 quietly retires most of that work. Not with fanfare, not on the WooCommerce 11.0 release notes stage, and not with a settings screen most merchants will find on their own. In a beta feature you have to opt into.

What is actually new

On August 6, 2026, the WooCommerce Developer Blog published Introducing Reconciliation Reports for WooPayments, author oleksandraratovskyi. The post announces a new area under Payments → Reports that ships in WooPayments 10.9 as a beta and rolls out gradually. Two reports live there today.

The Balance Report is the headline. Pick a period and it walks the account movement in the order the accountant already thinks in: Starting balance → Charges → Fees → Refunds → Disputes → Payouts → Ending balance. Print a summary or export the detail to CSV. That single line is what the manual reconciliation ritual has been trying to reproduce for years, and the reason the numbers line up is that the calculations run in UTC to match Stripe’s own figures.

The Fees Report is the companion, and the one your finance team will open second. It lists every fee-bearing transaction with date and time, payment method, type, order ID, transaction ID, currency, gross amount, and total fees, filterable by date, method, or type. That is the audit trail behind the Balance Report’s fee row.

The feature is behind a flag while it stabilises. Enable it in a snippet plugin or a small mu-plugin with add_filter( 'pre_option__wcpay_feature_reports_area', fn() => '1' );, or via WP-CLI with wp option update _wcpay_feature_reports_area 1. The Woo support team can also turn it on for merchants who do not want to touch code. The developer post lists scheduled exports, multi-currency support, and dedicated payout reconciliation views as candidates for follow-up work.

Two calendar notes for context. This lands two days after WooCommerce 11.0 on August 4, and on the same day as the second half of the week’s Stripe for WooCommerce security advisory. It is a WooPayments release, not a WooCommerce Core release, and it is not the same plugin as Stripe for WooCommerce.

Why it matters for WooCommerce people

Reconciliation is one of those unglamorous problems where the marketing site is quiet and the retainer conversations are loud. Every store above a certain size has this problem. Most solve it with spreadsheets and one person’s institutional knowledge. When that person leaves, the reconciliation stops making sense to the next hire, and the agency gets a ticket asking why the payout from a Tuesday two months ago is fifteen euros short.

Moving that report inside the WooCommerce admin does three concrete things. It kills the CSV round trip, which is where most of the reconciliation errors actually live. It puts the calculation in the same place as the raw data, so a disputed transaction on Monday is a corrected balance line on Tuesday without anyone re-running an export. And it uses the same UTC clock as the payment provider, which quietly ends the “why does our number differ from Stripe’s number by nine hours of transactions” argument that every multi-timezone merchant has had at least once.

The wider signal is the same one I read into the WooCommerce Core Foundations initiative and the two internal-review security advisories this week. Woo is moving load-bearing operational work off third-party plugins and into the core surface, where it stays supported and versioned. Reconciliation is a small stone in that wall. It is also the kind of feature you notice most on the second month, when the ritual is quieter than it was on the first.

What I would do (or not do) about it

Beta means beta. Turn it on this week on one staging environment for a client who runs WooPayments and actually reconciles monthly. Point them at the Balance Report for last month’s period and ask a single question: does the ending balance match what your accountant landed on. If yes, you have your answer. If no, that gap is the interesting number and the developer post is honest about the fact that edge cases still exist while the surface stabilises.

Do not enable it fleet-wide today. The flag exists for a reason and there is no shortage of production stores where an unfamiliar report tab appearing in the admin generates its own support ticket queue. Turn it on where you have a stakeholder ready to look at it and give feedback. Everywhere else, wait for the “no longer beta” note in a future WooPayments changelog and then flip it on a regular change window.

Do not, please, install a plugin whose entire pitch is “adds reconciliation reports to WooPayments.” The reports are shipping in WooPayments itself. A third-party wrapper on top of a first-party feature that is still in beta is the definition of technical debt you did not need. If you have a spreadsheet-based reconciliation process today, keep it running in parallel for a month once the beta is on. Prove the two agree, then retire the spreadsheet. That is how you migrate off a decade-old workflow without losing the audit trail on the way.

The internal Retool dashboards and the mu-plugins that pull Stripe transactions can retire more slowly. They were built when the alternative did not exist. Now the alternative exists, in beta, from the vendor, versioned with the plugin. Give it two months in production before you archive the custom code, then archive it with a note that says why.

Reconciliation is not glamorous and neither is this feature. That is exactly why I trust it more than the ones that ship with a launch video.