A WooPayments payout can leave the available processor balance before the bank posts the deposit. If accounting compares only the ending processor balance with current bank cash, the in-transit amount looks missing. A clearing ledger preserves the payout ID and timing so the movement is visible without recognizing revenue twice.
Use this for stores that reconcile WooPayments daily or monthly, especially when weekends, holidays, multiple currencies, reserves, disputes, or bank processing delays make payout timing hard to follow.
Quick answer
Open one clearing entry when WooPayments creates a payout, keyed by payout ID and currency. Move the payout net amount from processor cash to cash in transit, then clear that entry when the matching bank deposit posts. Keep fees, reserves, and disputes in their own lines, and alert when an open payout exceeds the expected arrival window.
What to check first
- Export payout ID, status, currency, gross activity, fees, adjustments, net amount, creation time, and expected arrival date.
- Match each payout to processor balance transactions before looking for the bank deposit.
- Use a dedicated cash-in-transit account instead of posting the payout as revenue or an unexplained adjustment.
- Match bank deposits by payout ID where available, then by exact net amount, currency, date window, and account.
- Age every unmatched payout and record the owner, expected clearing date, and escalation evidence.
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 |
| Normal payout | One completed payout and exact bank deposit | Clearing entry opens and closes with zero residual |
| Weekend transit | Friday payout with Monday or Tuesday arrival | Open item remains expected until the documented arrival window |
| Multi-currency payout | Two payouts in different settlement currencies | Each currency uses a separate clearing balance and bank match |
| Returned payout | Failed or returned bank transfer | Original entry is reversed or reclassified with status evidence |
Decision rule
Leave an item in transit while its payout status and expected bank arrival remain valid. Escalate when the amount, currency, destination account, payout status, or age falls outside the documented contract.
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.
- Create the clearing account and define when entries open, clear, reverse, and escalate.
- Load payout records with stable IDs, currencies, dates, components, and status.
- Post the processor-to-clearing movement when each payout is created.
- Match and clear the bank deposit without changing revenue.
- Review aged residuals and retain evidence for returns, reserves, and manual adjustments.
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
| Create the clearing account and define when entries open, clear, reverse, and escalate. | Export payout ID, status, currency, gross activity, fees, adjustments, net amount, creation time, and expected arrival date. | Processor cash plus clearing plus bank cash reconciles for each currency and close date. |
| Load payout records with stable IDs, currencies, dates, components, and status. | Match each payout to processor balance transactions before looking for the bank deposit. | Every bank deposit maps to one payout ID or an approved grouped-settlement rule. |
| Post the processor-to-clearing movement when each payout is created. | Use a dedicated cash-in-transit account instead of posting the payout as revenue or an unexplained adjustment. | Open items have an age, expected date, evidence link, and accountable owner. |
| Match and clear the bank deposit without changing revenue. | Match bank deposits by payout ID where available, then by exact net amount, currency, date window, and account. | Cleared items produce no residual and do not create duplicate revenue or fees. |
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
payout_id,currency,created_at,expected_arrival,processor_net,bank_amount,status
po_80214,USD,2026-08-07T18:42:00Z,2026-08-10,18420.55,,in_transit
po_80198,USD,2026-08-05T19:02:00Z,2026-08-07,9211.30,9211.30,cleared
po_44012,EUR,2026-08-06T10:20:00Z,2026-08-11,4470.00,,review
Production verification checklist
- Processor cash plus clearing plus bank cash reconciles for each currency and close date.
- Every bank deposit maps to one payout ID or an approved grouped-settlement rule.
- Open items have an age, expected date, evidence link, and accountable owner.
- Cleared items produce no residual and do not create duplicate revenue or fees.
Why this usually happens
- Processor and bank systems recognize the same cash movement at different times.
- Net payouts combine sales, refunds, disputes, fees, and adjustments that cannot be reconstructed from the bank amount alone.
- Teams sometimes reuse order numbers for payout reconciliation even though the payout groups many transactions.
Field notes
- The payout ID is the primary key. Amount and date are matching aids, not a unique identity.
- Keep one ledger per settlement currency so exchange movement is not hidden inside payout timing.
- An aged item is a question to investigate, not permission to force a balancing entry.
Mistakes to avoid
- Do not record the bank deposit as a second sale.
- Do not combine currencies in one unexplained clearing balance.
- Do not match by amount alone when repeated payout amounts are possible.
- Do not clear an old item with a manual journal entry before resolving its payout status.
What to tell the client or owner
Provide open and cleared payout IDs, currencies, processor net, bank amount, expected and actual arrival dates, aged exceptions, status evidence, journal references, and reviewer.
Questions teams ask during testing
When should the clearing entry open?
Use a consistent policy tied to payout creation or the processor balance movement, then apply it to every payout.
What if several payouts reach the bank as one amount?
Document the bank grouping rule and preserve every underlying payout ID in the match.
What age is too old?
Compare age with the processor status, expected arrival, bank calendar, and store policy. Set an alert threshold that catches exceptions before close.
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, build a WooPayments clearing workflow.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references