The shop loads again. Somebody breathes out, somebody wants maintenance mode removed, and somebody discovers missing orders. That last detail has a habit of appearing just when recovery looked finished.
After restoring a hacked WordPress site, WooCommerce order reconciliation means connecting each operation to its payment, recoverable order details and events that already happened outside the shop. Matching the revenue total or setting everything to “processing” does not establish that connection.
This guide provides a worksheet, six fictional cases and an original local exercise showing misleading totals. Use it to commission and review recovery, rather than as an import script or instruction to charge customers. If recent transactions are affected, request an urgent WooCommerce recovery assessment before overwriting another database.
What the worksheet resolves, and what needs technical work
The worksheet organises decisions: which operation exists, what is missing, which source supports each fact and who can approve the next step. Extraction, integrity assessment and import belong to the agreed technical process. A business inventory does not turn a compromised database into a trusted source.
If you need to distinguish actual loss from an order-storage mismatch, start with the guide to missing WooCommerce orders after a backup restore. Here, the starting point is preserved evidence and a shared record that lets business staff work with the recovery specialist.
Name a reconciliation owner and deputy. Avoid separate warehouse, support and development spreadsheets with incompatible rules. Each team may contribute different evidence, but each decision needs a common reference and somebody authorised to resolve disagreements. Record who last reviewed the entry so another person can continue without guessing.
Set the time window before counting orders
Record the restored backup’s timestamp, containment time, preserved sources and intended cutover. Use an explicit timezone. Distinguish order creation from authorisation, capture, refund and dispatch times. Those events may belong to different moments in the recovery window.
Do not calculate missing orders by subtracting two sequential order numbers. Preserve operation and event references with their source. If a system exposes only part of the period, document that limit. An apparently complete spreadsheet can still contain an unobserved interval that no one has investigated.
Agree which system governs new activity and who controls outstanding effects during the investigation. The procedure for protecting recent orders during emergency recovery covers preservation and cutover. This worksheet records their outcomes; it does not replace them with an improvised import.
Fields for an order-reconciliation record
Create one record per candidate operation. References can point to protected documents. Do not copy addresses, card data or entire webhook payloads into a broadly shared spreadsheet for convenience. The owner should be able to locate authorised evidence without multiplying sensitive working copies.
Record: REC-___ | owner and review date:
Provider reference / former order / recovered order:
Source and timestamp of each observation / timezone:
Operation amount and currency:
Observed financial state / capture / refund:
Order in restored copy: yes / no / not verified
Recoverable detail: items, quantities and relationships:
Fulfilment, stock, access and messages already actioned:
Discrepancy or fact still unknown:
Proposed action / approval / dependency:
Isolated trial and outcome / side effects controlled:
Closure: evidence / owner / outstanding items:“Not verified” and “does not exist” are different answers. A single dashboard search does not establish absence from every preserved source. Matching amounts do not establish identity either: record the provider’s transaction identifier and its verified relationship to the order.
If an internal order identifier changes, preserve the old-to-new mapping and reason. The record should allow an authorised reviewer to trace an operation through recovery even when the clean system cannot reuse exactly the original internal identifier. An unexplained renumbering makes later support considerably harder.
Six fictional cases with different next decisions
Every case in this table is fictional. Amounts, references and states support a review discussion, not automatic actions. No row authorises charging, refunding, shipping goods or changing production. Real decisions require the provider, business owner and technical evidence appropriate to that operation.
| Record | Fictional financial evidence | Restored shop | Next check |
|---|---|---|---|
| REC-01 | 120 EUR captured | Order and transaction reference match | Review fulfilment and effects already actioned |
| REC-02 | 80 EUR captured | Missing order; protected later details available | Prepare reviewed recovery on an isolated copy |
| REC-03 | 60 EUR authorised, not captured | Order present | Check provider state; do not mark as collected |
| REC-04 | 90 EUR captured and 90 EUR refunded | Backup retains an earlier state | Reconcile refund history; prevent another dispatch |
| REC-05 | 75 USD captured | Candidate order for 75 EUR | Hold association because currencies disagree |
| REC-06 | 45 EUR captured | Missing order and no item details | Keep unknowns explicit and assess other sources |
REC-01 may look resolved, but shipment and stock effects still need checking. REC-02 has a candidate source, not permission to restore the entire later database. REC-06 has observed money in the scenario, but no basket that the team is entitled to invent.
For each record, write the question that unlocks progress. “Check order” is too broad. “Confirm whether the carrier accepted the parcel before cutover” gives somebody a specific investigation with a recordable outcome. The worksheet becomes useful when its unknowns lead to owned checks.
How to review REC-02 without calling it recovered
Take the fictional 80 EUR entry. Business staff know about the payment, but the restored backup has no corresponding order. A protected later snapshot appears to contain details. The first decision is to assess that source. Its integrity and the availability of every required relationship have not yet been established.
The technician records the source and fields recoverable through the approved procedure. Business staff contribute evidence of dispatch, allocated materials and messages already sent. If a new internal identifier is proposed, the record connects the old reference, new reference and provider operation. A matching amount alone does not establish that relationship or justify importing the candidate.
For the trial, agree inputs, expected output and effects that must remain blocked. Subsequent approval cites observed evidence and exceptions rather than a generic success statement. If an indispensable detail is unavailable, the record stays pending with an owner and next investigation. This expanded REC-02 example remains fictional: we have not extracted or restored a real order, and a later snapshot is not a promise that every required detail survives.
Our local exercise: two lists total 300 EUR but contain different operations
On 24 October 2026 at 23:30 UTC, we ran a local Python exercise using decimal amounts and identifier sets. It compared two synthetic three-operation inventories without connecting to WooCommerce, a payment gateway or a customer database.
Fictional original list: DEMO-A 120 | DEMO-B 80 | DEMO-C 100 EUR
Fictional restored list: DEMO-A 120 | DEMO-B 80 | DEMO-X 100 EUR
Each list totals: 300.00 EUR
Missing reference: DEMO-C
Unexpected reference: DEMO-XThe observed result was equal totals, with one missing identifier and one unexpected identifier. We deliberately changed the third reference to expose the limit of a sum. This was not evidence of fraud, successful recovery or import compatibility. No real shop or financial operation was involved.
The practical implication is to review identities and relationships alongside quantities. A total is a useful control, but it cannot establish that the correct operations are present. A real intervention must also compare currencies, subsequent events and authorised sources. This small demonstration is not a production reconciliation engine.
Payments and order labels: retain the actual observation
A WooCommerce status label is not a substitute for provider evidence. The official status documentation describes distinctions and exceptions. Record the specific observation and relevant notes before proposing a change.
Separate authorisation from capture and check the gateway configuration. The WooPayments documentation describes that distinction for its product; do not apply its deadlines or behaviours to a different provider without verification.
Partial refunds, disputes and pending operations need their own review branches. The table does not cover every scenario. Where evidence is missing or states disagree, retain the discrepancy and assign the next contact. Changing a label to make a screen look reassuring does not recover the missing information.
Storage and relationships: an order is more than one row
The official HPOS documentation distinguishes authoritative and backup tables. Ask the technician to identify storage for each preserved copy. Table synchronisation should not be treated as an independent historical backup.
Record whether items, quantities, variations and necessary business relationships have been validated. A shop with subscriptions, bookings or downloads needs those systems reviewed too. The minimum recoverable information depends on the real operation, rather than the fields that happen to fit this worksheet.
Avoid filling gaps from today’s catalogue without checking. A product’s price, tax treatment or configuration may have changed since the original operation. If a source does not retain the required detail, leave it unknown and agree how the discrepancy will be investigated. A plausible basket is not an evidenced basket.
A visual reference for separating overview from detail
An overview helps you locate where to investigate. Decisions need the underlying operation. Keep both levels in the evidence record: how many entries remain open and what specific information is missing from each one.
An isolated trial must check effects as well as records
Before the approved change, agree what will be tested on a protected copy. Identify the operation set, intended mapping and controls preventing duplicate charges, emails, shipments, synchronisation or access grants. A disabled-looking button does not prove every automated process has stopped.
The technician records the controls applied and what the trial excludes. Business staff review the entries and observed effects. Where appropriate, a controlled second run needs explicit consideration to detect duplication; reusing the same file is not proof that repetition is safe.
Retain the outcome per operation and unresolved failures. Do not publish a real customer export as a worked example. The post-recovery cart, checkout, order and account tests complete functional acceptance; reconciliation follows the pre-cutover business records.
What an order-recovery intervention should deliver
Ask for a source inventory with limits, reviewed time window, reference mappings, approved decisions, trial results and exception list. Establish who retains evidence, who may access it and who is responsible for unresolved entries after the recovery specialist hands over.
Separate “operation identified”, “sufficient recovery data”, “recovery tested” and “accepted by the business”. They are different milestones. A record with a known payment and unknown items should not disappear from the report because the overall revenue total agrees.
Reopening also needs technical resolution of the compromise. Reconciled orders do not establish trustworthy access or code. The WordPress recovery plan for 2027 helps assign those decisions and their owners before the next emergency.
Prepare a recovery quote without sending customer data
An initial assessment needs the domain, backup and restoration dates, timezone, approximate volume and available sources. Explain whether orders continued arriving and whether subscriptions, ERP, warehouse systems or multiple currencies are involved. A description is enough to start defining scope.
Ask for preservation, analysis, isolated trial, recovery and acceptance to be scoped separately. Source availability and reliability determine what can be recovered. Confirming those limits before choosing an import is more useful than discovering them after the only later record has been overwritten.
The evidence record should leave every operation with a defensible decision: recovered and verified, awaiting an identified check, or limited by unavailable information. Support and business staff can then continue from a shared record instead of another round of “I think it is fixed”.