The orders your sales report does not know you made

September 4, 202618 min readUpdated September 13, 2026

A customer agrees the job on WhatsApp. You send a payment link, they pay, and you key the order into the admin by hand. The money is in your bank. At the end of the month the sales report shows a figure you did not bank, the conversion rate has apparently fallen, and neither number will explain itself. Orders not showing in sales reports start here.

Orders not showing in sales reports are usually sitting somewhere else inside the same system: counted under a label nobody recognises, or parked in a status the report was told to ignore. Which of those you have depends on the platform.

Every page below was read in August 2026, and where a claim rests on a vendor's sentence, that sentence is quoted. Where it rests on inference, or on a post in a support forum, that is said too.

Which businesses does this actually hit?

Four shapes, and plenty of shops are none of them. A shop where every order is a card payment taken at checkout does not have this problem, because there is nothing for the report to miss. Trouble starts wherever an order is agreed in one place and recorded in another, by a person.

Trade and wholesale accounts invoiced on terms, where goods leave before the money arrives.
Service firms taking a deposit now and the balance on completion.
Deals closed on WhatsApp or by phone and typed in afterwards.
Shops offering bank transfer alongside card, so some orders wait for a human to confirm the money landed.

If one of those is more than a rounding error in your week, the rest of this is about your business.

Why are two of your numbers wrong in different directions?

Because revenue and attribution - the record of where a sale came from - are calculated from different things, and an off-checkout order lands in one while slipping out of the other. Shopify counts a converted draft order as revenue, then credits it to a bucket called Draft Orders. The conversion rate, meanwhile, is a percentage of website sessions that order never had.

So the total is roughly right and the breakdown is wrong. You read the channel report and conclude WhatsApp is not worth staffing, when every WhatsApp deal is filed under how it was typed in. Three Shopify pages produce that story between them, and none warns you about the other two.

What does Shopify do with an order that started as a draft?

It counts the money and loses the origin. Shopify's sales report documentation states that "the sales reports include sales and reversals from open, archived, pending, and canceled orders, as well as draft orders that have been converted into orders". A converted draft is revenue. A draft left unconverted is revenue nowhere.

The attribution is the part that bites. On the same page, under sales by sales channel, Shopify writes: "For sales that originated as draft orders, the report displays Draft Orders." A deal closed on WhatsApp, entered as a draft, converted and paid gets credited to the act of typing it in. Every channel you sell through by hand collapses into that one cell.

A shop described exactly this flow in Shopify's community in July 2026. The poster, who carries no staff badge, writes that customers "interact with our staff or automation via WhatsApp to place orders". The draft is converted once an external payment link is paid. No Shopify staff replied to the thread.

Does the conversion rate count a phone order?

By Shopify's own definitions it cannot, though Shopify never says so in a sentence. The field definitions page defines conversion rate as the "percentage of online store visits (sessions) that resulted in a sale". It defines sessions as the "number of online store visits", adding: "Only counted when visitors consent to cookies through your cookie banner". An order typed into the admin has no visit.

That is a conclusion drawn from two published definitions, and it should be read as one. No vendor sentence says draft orders are excluded from the conversion rate, and I am not going to invent one.

Shopify does concede the two sides of the fraction come apart. Its behaviour reports page notes: "It is possible for a customer to make multiple purchases during a single session. For this reason, your order count and your sessions that completed checkout count might not be the same."

The order count takes everything. The conversion denominator takes only people who came through the website and accepted cookies. Grow the phone and WhatsApp side of the business and the rate falls in a month when you sold more.

Why is the conversion summary on that order empty?

Because it is a different measurement with its own reasons for being blank. The conversion summary is an order-level panel showing a customer's visits before that purchase. Shopify lists the possible reasons it comes up empty, and the second is short: "The order was originally a draft order."

Two other reasons on the same list look identical on screen. One is cookie tracking blocked by apps or private browsing. The other is an order that "didn't come from your Online Store or Hydrogen sales channels, and no source or landing page is associated with the order".

Shopify also documents a middle state, where "the order can still display limited conversion details based on order attribution". Partial data reads as complete data to anybody never told otherwise. Do not treat this panel as evidence about the store conversion rate.

If you would rather have that arithmetic done on your own order mix, that is what the process audit is for. $299, three business days, and a written map of where each kind of order enters and what it is worth. You keep the map whether or not you hire us, and the fee is credited towards the project.

What does WooCommerce count as revenue, and who do you believe?

Here the documentation and the support desk answer different questions, and only one of those answers is published where you would look for it. The analytics documentation says which order statuses Analytics counts. WooCommerce's support staff, answering a customer in January 2026, describe a narrower rule for the Revenue report specifically. A bank transfer order falls straight between the two.

The documentation is explicit: "By default, Pending payment, Cancelled and Failed order statuses are excluded while Processing, On hold, and Completed order statuses are included." Read plainly, On hold is included.

Now the support thread. On the WordPress.org forum, a customer reported that the Revenue report showed only Processing orders. A reply from shahzeen (woo-hc), labelled Plugin Support, states that "the Revenue report is intentionally different. By design, it only reports on paid orders, which means Processing and Completed statuses".

A second Plugin Support account, Sai (woo-hc), answered in the same thread: "the Revenue report only includes paid orders. By design, that means Processing and Completed statuses. Other statuses (On hold, Pending, Failed, Cancelled) are not counted as revenue, even if they aren't listed under 'Excluded order statuses.'"

Both accounts carry the woo-hc suffix used by WooCommerce's own support crew. The settings screen states the rule for Analytics generally. Support adds that the Revenue report is a deliberate exception to it, and that exception appears on no documentation page I could find.

Bank transfer, and the status it leaves the order in

It parks the order in the exact status the disagreement above is about. WooCommerce documents its bank transfer method as "an offline payment method, meaning that the payment process is manual and happens outside your WooCommerce powered store". The same page says "the order is set to "On hold" in WooCommerce" and that "you the store owner must check your bank account for this incoming deposit before processing their order".

The status glossary fills in the rest. On hold means "the order is awaiting payment confirmation. Stock is reduced, but you need to confirm payment." Processing means "payment has been received (paid), and the stock has been reduced." One person ticking something is the whole difference.

So the money is in your bank, the order says On hold, the settings page implies On hold is counted, and support says Revenue counts paid orders only. Whoever falls behind on marking transfers received is setting your revenue figure.

Two smaller details belong here. Orders keyed in by staff get an attribution origin the docs describe as "manually Add an order from the backend", labelled Web Admin. And core WooCommerce Analytics lists no conversion rate report, so there is no conversion metric there to be wrong.

When does a Square invoice become a sale?

When it is paid in full, and not a day earlier. Square says so twice over on one page about deposits: "A transaction for the invoice will not appear until the invoice is fully paid off." The same page adds that with progress invoices, "sales are not recorded within Sales Reports until the entire invoice is fully paid".

Take a deposit of half the value in March against an invoice settled in June. March's sales report does not contain it. June's contains all of it. A month-to-month comparison there measures your invoicing calendar.

Sellers find this the hard way. In a Square community thread running into January 2026, a seller reported that "invoices created in 2024 but paid in 2025 are showing as sales in 2025, not 2024". That seller carries the Square Champion badge, which is a customer recognition programme rather than a staff role. The accepted answer came from another Square Champion, and it is the fairest line anybody has written on this: "Square is actually recording and reporting in the way that you want. The UX may not be communicating that in the clearest way".

What happens when the money never went through the system?

The report and the bank stop agreeing, and each vendor handles it differently. An invoice paid by transfer and ticked off by hand has no payment event inside the system that issued it. Stripe documents that precisely. Square's help pages mostly do not.

Stripe's invoicing documentation covers invoices reaching paid without a payment going through Stripe: "In these cases, you receive the invoice.paid event, but no invoice.payment_succeeded event." Those event names are the messages Stripe sends other systems when something happens to an invoice. Anything wired to the second will never hear about a bank transfer.

That matters when a bookkeeping connector or an automation listens on the payment event, the obvious one to pick. The work runs on schedule, finds nothing to do, and looks exactly like a quiet week. The general version of that problem is why automations fail silently.

Stripe's revenue recognition documentation covers the accounting side, and it is a separate product not every Stripe user has switched on. "When you manually mark invoices as paid outside of Stripe, the external asset account increases. All other accounts operate as if the invoice is paid, but the cash account doesn't change."

On the Square side, a customer asked in July 2025 whether an invoice marked paid by direct deposit is "added to the total square income report received". The only answer in the thread came from a former Square employee, and the help article that ought to settle it would not load when I tried it twice. So the honest answer is that Square does not publish one. A payment that landed in your bank rather than through Square is the case to test before you trust the report.

Every order type, and what each system counts

One table, with a warning attached. Nobody publishes a matrix like this, so every cell came from a separate page and the empty cells are honest. "Not documented" means no vendor page read in August 2026 answers it. "Inferred" means it follows from two published definitions rather than a quote.

Order type	In sales revenue	In conversion rate	In channel attribution	Reaches accounting
Storefront checkout	Yes. Shopify counts open, pending, archived and cancelled. Woo docs say Processing, On hold and Completed; Woo support says the Revenue report counts Processing and Completed only	Yes for Shopify, on online store sessions. Woo core has no conversion metric	Yes. Shopify names the channel; Woo records source, organic or referral	Not documented
Draft or manual order, converted	Yes. Shopify: "draft orders that have been converted into orders"	Inferred no for Shopify: no online store session exists. Woo: no metric	Shopify: bucketed as Draft Orders. Woo: origin Web Admin	Not documented
Draft order not yet converted	Inferred no. Only converted drafts are listed as included	Inferred no	Not applicable	Not documented
Point of sale	Not documented whether POS sales also reach the main sales reports; POS has its own report set, covering "only sales that were made at a POS location"	Inferred no: no online store session exists	Shopify: POS is a channel, with a staff-level report	Not documented
Square invoice	Only when fully paid: "A transaction for the invoice will not appear until the invoice is fully paid off"	Not documented. No conversion metric on pages read	Not documented	Not documented. Square records other tender "for tracking purposes only" but not how it reports
Stripe invoice	Recognised over the service period, not on payment: Stripe books revenue in the month the invoice covers even when it is paid later	Not applicable	Not applicable	Out of band: `invoice.paid` fires, `invoice.payment_succeeded` does not
Marketplace	Not documented	Not documented	Shopify's channel report names the channel or app used	Not documented
Cash or transfer keyed in	Woo transfer sits On hold; Woo support says Revenue counts paid orders	Inferred no	Woo: Web Admin if keyed into the admin	Not documented

The second column reads reassuringly. Then the third and fourth undo it. Most off-checkout money gets counted as revenue once somebody ticks the right box, and almost none of it is credited to where the sale came from.

One Shopify sentence stands over the last column: "Sales reports don't track money moving between you and your customers." The same page adds that "depending on how you've set up your payment methods, you might not receive the actual payment until a later date". A sales report records goods sold, and your bank statement records money.

What do the vendors not tell you?

Four things, and knowing which questions have no published answer is worth as much as the answers. Vendors document what their product does on a good day. The seams between products, and the cases needing a person, are where the documentation stops.

Shopify POS against the main sales reports. The POS reports "include only sales that were made at a POS location. Other sales are excluded from the reports." No page read states whether POS sales also appear in the main sales reports.
Marketplaces. No vendor page read in this pass states how a sale made on a marketplace outside your store is treated. A marketplace connected as a Shopify sales channel appears in the channel report. The rest is guesswork, and I am leaving it as guesswork.
WooCommerce and dates. The docs say "the default date type is 'Date Paid.'" Check that yours has not been switched to Date created, because the same month's revenue moves when it is.
The page you would open first. Shopify's help page on report discrepancies deals with Shopify against third-party trackers. Draft orders, manual orders and POS do not appear on it.

Where do orders not showing in sales reports actually go?

Into one of three places, and telling them apart takes an evening with your own data. They are counted but mislabelled, uncounted because a status was never changed, or uncounted because the sale lives where no report can see it.

Counted but mislabelled. The revenue is in the total, credited to Draft Orders, Web Admin or an app name. Your channel breakdown is fiction.
Not counted yet. A Square invoice part paid, a WooCommerce order on hold, a draft never converted. The report is waiting on a human action nobody scheduled.
Counted nowhere. The deal was agreed in a chat, paid by transfer, and written on a delivery note.

Take last month's bank statement and last month's sales report and reconcile them by hand, once. The gap is where your orders not showing in sales reports actually are, and businesses of these shapes tend to find all three cases inside one month.

How do you fix this without buying anything?

Decide which single system is your revenue system of record, then put every order into it as an order. Both platforms above already have a place for an off-checkout sale: a draft you convert, or an order created in the admin with its own attribution origin. Using it costs a habit rather than a licence.

Name the system of record, out loud, once. One system holds every order. Keep a spreadsheet of WhatsApp deals alongside it and you have two systems of record and no revenue figure.
Enter off-checkout orders as orders, rather than as notes or messages left in the chat. This is the whole fix, and the part people skip, because typing it in feels like duplication.
Add your own channel field. The platform will label it Draft Orders or Web Admin. A tag reading whatsapp, phone, trade or walk-in gives you the breakdown the platform cannot.
Decide what each status means and who moves it. Transfer received, deposit taken, balance paid. Then check that the report setting agrees with the meaning you chose.
Reconcile monthly against the bank. An hour, and it catches what the other four steps miss.

Those five cost nothing and need no software. Only when the typing itself becomes the bottleneck does automation earn a look, and the same order of operations applies here as anywhere: start with the process, not the platform. What such an automation would cost is the arithmetic in what automation costs a small business.

What to check this week

Five checks, none needing a developer, and each one turns a suspicion into a number you can write down. Do them in the order below, because the first usually explains the other four, and stop as soon as the arithmetic accounts for the gap.

Pull last month's total from your sales report and last month's takings from your bank. Write the difference down before you try to explain it.
Open your channel or attribution report and find the bucket named after a data entry method. That is your off-checkout revenue, unattributed.
Count your open and part-paid invoices, then ask which report they are in. Check the vendor's current page rather than trusting this one.
Find every order in a status that means "waiting for a human". Ask who that human is.
Test one order end to end. Enter a small off-checkout sale the way your staff do it, then look for it in the revenue report, the channel report and your accounting system.

That last test is the only one answering the question for your setup rather than for the vendor's documentation. Defaults get altered by whoever set the shop up three years ago.

Where the order arrives as a PDF purchase order, getting invoice data out of PDFs covers that half. Where money going out is matched against what a supplier says you owe, the checks run the other way, in the checks before paying a supplier invoice.

If you would rather have somebody map where every kind of order in your business enters, gets counted and reaches the books, that is what the process audit produces. In writing, in three business days.