Three green lights, and not one of them counts what arrived

The number no screen shows you

Ask the simplest question there is — how many orders reached the accounts yesterday — and there is nowhere to look. The shop reports Connected. The connector reports a successful sync. The order reports Processing. Three indicators, across two systems, and not one of them is a count of records delivered.

That gap is what this article is about. It arrives on the support forum every few weeks in three different shapes that need three different answers, and ten minutes of looking tells you which one you have.

Which of the three indicators counts a record?

Put them side by side and the problem becomes obvious.

Underneath, the timing is looser than "Connected" suggests. QuickBooks Connector — the free integration pairing WooCommerce with QuickBooks Online — syncs on a schedule: "your account should sync every hour, but you can set up a manual sync at any time". Between the connection being live and the data being there sits a separate process with its own outcome.

The useful move is to stop treating "in the shop but not in the accounts" as one problem. It is three, they have different fixes, and ten minutes of looking tells you which one you have.

Nothing ever used the key

In one case an owner watched orders stop reaching QuickBooks in late May and only chased it in August — about four and a half months by the time you read this. The integration said Connected the entire time. He went to check the WooCommerce side and reported what he saw:

Orders were syncing previously, but the synchronization stopped on May 26, 2026. The QuickBooks integration status still shows Connected. New WooCommerce orders are not appearing in QuickBooks. We contacted QuickBooks Support, and they advised us to check the WooCommerce side. We checked the WooCommerce REST API settings and created an API key with Read/Write permissions. However, this API key is showing as "Unknown Access" in WooCommerce.

• a store owner, WordPress.org support forum, August 2026

There is no such thing as "Unknown Access" in WooCommerce. He was reading two adjacent columns as one phrase, and once you separate them the screen is telling him the answer.

The REST API table has a Permissions column, which returns Read, Write, Read/Write — or, if the stored value is none of those, nothing at all. Next to it is a Last access column, and "Unknown" is what that column shows when the field is empty. So the row said: this key may write, and nothing has ever successfully used it.

That field is written in exactly one place in WooCommerce — after a request has authenticated and passed its permission check. Which gives you four things worth knowing:

• "Unknown" on a key that has been live for a day means no request from outside has ever authenticated and passed its permission check with it. Not a slow sync. None. Two things stop that being absolute: requests WooCommerce generates internally are deliberately not recorded — the code says so in as many words — and a filter added in 7.7.0 can switch the recording off entirely. Neither applies to an outside connector calling the REST API over HTTP, which is the case in front of you.
• A read-only key used by a writing integration stays "Unknown" forever, because the permission check fails before the timestamp is written, and each attempt returns a 401 saying the key lacks write permissions.
• A WooCommerce key only authorises WooCommerce routes — anything under wc/ or wc-. A request to the general WordPress API is not covered by it at all.
• A brand new key always starts as "Unknown", so the signal is only meaningful once the integration has had time to run.

And there is a tell for the specific failure in that thread. When a connector authorises itself properly, WooCommerce creates the key and names it automatically, in the form <App name> - API (2026-03-02 11:40:07). A key you created by hand does not look like that — and if the connector authorised itself through that endpoint, it does not know your key exists and will never use it. Its Last access stays Unknown no matter how long you wait, and creating a key manually to fix that kind of connection is a reasonable thing to try that cannot work. Integrations where you paste the consumer key and secret into a settings field are the other kind, and there a hand-made key is exactly right — check which one you have before concluding anything from this row.

The awkward part: WooCommerce's own REST API documentation page never mentions the Last access column. Its meaning is recorded only in the source code. The single most useful diagnostic on that screen is the one nobody wrote down, which is a fair explanation for why an owner read it wrong.

It arrived, and the receiver filtered it out

The second branch is the one that makes people doubt their own eyes, because the sending tool is telling the truth as it understands it. A push completed. A 200 came back. From the sender's side that is success.

A shop owner ran into this in August, with a point-of-sale system pushing products into WooCommerce. She had already narrowed it down herself, and knew how the conversation usually goes, so she asked in advance for it not to go that way:

We've already done quite a bit of troubleshooting and have narrowed the problem down to woocommerce rejecting the api call. – please do not jump to "this is a third party problem"! Octopus Bridge reports that the product sync/update completes successfully. […] Despite the successful push, the new product is never created in WooCommerce and the WooCommerce product count does not change.

• a store owner, WordPress.org support forum, August 2026

She was right about where it was happening: the request reached the site. What the receiving end did with it is the open question, and with QuickBooks Connector that part is configuration rather than malfunction. Setting it up involves choosing an account timezone, an integrations starting date, and rules about which orders sync — and order statuses act as filters, to the point that Intuit's troubleshooting page tells you to install an extra plugin so the connector can see custom statuses at all. An order dated before the starting date, or sitting in a status the connector was not told about, is skipped exactly as designed and silently.

That is worth stating plainly because it changes where you look. If the filter is doing its job, no log will show an error — there is no error. The record was considered and declined.

The same shape appears in an older Shopify-to-QuickBooks-Desktop thread, last active more than eighteen months ago, where products and customers synced fine while sales and purchases showed zero. The workaround one user eventually found was to switch the sync from detail mode to summary mode and back. That is not a fix to the connection. It is a change to the shape of the record the receiver was being asked to accept.

There was never a sync to fail

The third branch is the reason not to start by blaming the integration, and it comes from the same forum in the same few weeks.

A shop had twelve orders that never reached Stripe:

We have taken 12 orders that have not passed the payment over to Stripe in the last few days. […] Stripe is showing no errors and is not showing the missing order numbers. They are listed in WooCommerce ORDERS however. There does not seem to be any continuity to this re card type of time of day.

• a store owner, WordPress.org support forum, September 2026

Every instinct says integration failure. It was not. A support engineer asked, in the first reply, whether the orders had been marked Processing while bypassing payment entirely, and asked to see the order notes. Three hours later he closed the thread having found it: a second payment plugin installed on the site — an offline credit card payment method — was setting orders to Processing on its own, without Stripe being involved at all.

Two things in that exchange are worth more than the fix.

The owner had already found a plausible explanation of his own — that the payment methods were not enabled in Stripe — and the engineer declined to accept it: he was not sure how that would cause orders to bypass the gateway and land in Processing. The wrong explanation was reasonable, fitted the symptom, and would have sent everyone to the wrong system for a week.

And this thread is the counter-example to the "vendors point at each other" story. Same forum, same support team, same three weeks — eleven replies, real questions, cause found. The difference is not attitude. It is that this problem lived inside WooCommerce, which is what that team is responsible for. Which is the actual thesis here, and the last section comes back to it.

The webhook that switches itself off

One mechanism from the same family is worth knowing before it happens to you, even though it was not the cause in any of the three cases above.

If your integration is fed by WooCommerce webhooks rather than by polling, delivery is one attempt per event. There is no retry. And the failures accumulate:

WooCommerce automatically disables a webhook after more than five consecutive delivery failures.

• Webhooks documentation, WooCommerce

Success means a 2xx, a 301 or a 302; anything else counts against you. More than five in a row and the webhook sets itself to Disabled, permanently, with no email. The threshold is a filtered constant, so a site can move it, and the counter is compared before it is incremented — do not build anything on an exact number. On the Webhooks screen afterwards it looks like an ordinary row marked Disabled — indistinguishable from one somebody turned off deliberately months ago.

If your receiving endpoint had a bad afternoon, the integration can be switched off by that afternoon and stay off forever.

Five screens, ten minutes

All of these are in front of the owner, need no developer, and between them separate the three branches.

1. WooCommerce → Settings → Advanced → REST API. Read the Last access column. If a key that should have been working for a day says Unknown, nothing has ever successfully used it — that is branch one, and no amount of waiting changes it. Read the Description column too: a key created by a connector is named after the app with a timestamp, so a hand-made name means the connector does not know about that key.
2. WooCommerce → Settings → Advanced → Webhooks. Any row marked Disabled may have disabled itself after a run of consecutive delivery failures rather than having been turned off on purpose.
3. WooCommerce → Status → Logs, choosing webhooks-delivery from the source list. Response codes and messages are recorded here. One caveat that saves an hour: the bodies are not logged unless WP_DEBUG is on — the log says so in place of the content — so "nothing in the log" often means "no body in the log", not "no delivery".
4. The order notes on an individual order. This is where a support engineer started in the third case, and it is the fastest way to see which gateway changed the status and when. For anything shaped like "the money did not arrive", this is the first screen, not the last.
5. WooCommerce → Status, the System Status Report, specifically the active and inactive plugin lists. In the case that got solved, the answer was sitting in the active list: a stray payment gateway. In the point-of-sale case, the interesting line is in the inactive list — a Legacy REST API plugin installed but switched off. That older API was removed from WooCommerce core and moved into a separate plugin, so an integration still calling the old routes is calling something that no longer answers. Nobody in that thread established which routes the connector uses, so this is the first thing I would check rather than a diagnosis.

On the QuickBooks side, the connector lives under the accounting integrations section, with a Manage tab offering Synchronization Options and a manual Sync Now, plus the account timezone and integrations starting date that quietly decide what is eligible. Intuit's documentation covers setting all that up; I could not find a page describing where sync errors are displayed, which is not the same as saying no such screen exists.

Why does nobody own this problem?

The pattern in these threads is not indifference. Every answer was correct about its own product's boundary. By the owner's account, QuickBooks support told him to check the WooCommerce side — his phrasing, not a quote from Intuit. WooCommerce support, in writing, pointed at the connector and at QuickBooks. And the connector itself reported success, having from where it sat succeeded.

A problem that lives in the gap between two products is inside nobody's support scope by definition. That is structural, and it is why the third case got eleven helpful replies while the other two got a redirect: that one turned out to live inside WooCommerce, where somebody was responsible for it.

This is a different failure from an automation that has simply stopped running, where the problem is the absence of any signal at all. Here the runs happen, on schedule, and report success. The signal exists and is positive, and it is measuring something other than what you care about — which is harder to notice than silence, because it looks exactly like health. It is the same instinct as counting expected runs, one level deeper: a heartbeat proves the automation moved, a reconciliation proves the records match. On this failure only the second one speaks.

It is also the mirror image of having no connector for your channel at all. Nobody whose sales channel has no integration is under any illusion about where the data is. It is the shop with a working, paid-for connector that goes months without noticing.

When this is a job to hand over

Start with what the money says, because it is unusually clear here.

The free QuickBooks connector is free. MyWorks starts at nothing for twenty orders a month and runs to about a hundred dollars a month for unlimited, with sync frequency improving as you go up. Octopus Bridge charges a setup fee plus either per-order or monthly pricing. In the first case above the owner already had a working free connector and buying a paid one would have fixed nothing, because the problem was not capability — it was that nobody had looked in three months. In the second, the connector was paid for and reported success while delivering nothing.

The price of a connector does not buy observability. What these tiers differ on is order volume and how often the sync fires — that is what the pricing pages sell. Not one of them advertises the number an owner actually wants: how many orders reached the other side yesterday.

So the job is not the repair. It is the missing number: something that counts orders on one side, counts them on the other, and says both out loud on a schedule — plus a decision about the gap you find on day one, because there is always a gap and somebody has to key it in by hand. The five screens above come first whoever does the rest. They tell you which of the three you have, and the three are not the same size of job. That is how we scope this kind of work before quoting it.

The reason to do it this month rather than next is arithmetic rather than urgency. The owner in the first case lost most of a financial quarter before anyone noticed, and the work of reconstructing which orders went where grows every week it waits. Nothing in this failure escalates on its own. It just accumulates, quietly, behind three green lights.

Sources

• Product transaction not syncing to QuickBooks - WordPress.org support forum, August 2026, read 8 September 2026. Orders stopping in May while the integration showed Connected, the owner's report of what QuickBooks support told him, and the response recommending he contact QuickBooks. The description of the key as showing "Unknown Access" is the owner's phrasing of two separate columns.
• WooCommerce rejecting approved API calls - WordPress.org support forum, August 2026, read 8 September 2026. The request not to be redirected to a third party, the successful-push-nothing-created symptom, and the redirect to the connector's support and to community Slack. The site's own status report shows the Legacy REST API plugin installed but inactive, which is a hypothesis about the cause rather than a confirmed diagnosis — which API that connector calls was not established.
• WooCommerce taking orders but not all orders are taking payment via Stripe - WordPress.org support forum, September 2026, read 8 September 2026. Twelve orders in Processing without payment, the engineer's first question about orders bypassing the gateway, the rejection of the owner's plausible but incorrect explanation, and the cause recorded when the thread closed: a second offline payment plugin marking orders as Processing.
• WooCommerce source, the API keys list table, REST authentication, the auth endpoint and the webhook class - read 8 September 2026 from the trunk branch. The six columns of the REST API screen and the three values the Permissions column can return; Unknown as the Last access value for an empty field; the timestamp being written only after both authentication and the permission check succeed; the restriction of a WooCommerce key to wc/ and wc- routes; the naming pattern applied to keys created through the authorisation endpoint; the success codes for webhook delivery and the disabling of a webhook after consecutive failures; and the note that webhook bodies are not logged without debug mode.
• WooCommerce REST API documentation - read 8 September 2026. Covers creating a key and the permissions choice, and does not mention the Last access column at all.
• Webhooks - WooCommerce documentation, read 8 September 2026. The automatic disabling after more than five consecutive delivery failures, the three webhook statuses, and which response codes count as success.
• Connect WooCommerce to QuickBooks Online with QuickBooks Connector and Fix WooCommerce connection issues - Intuit, read 8 September 2026. The hourly sync with a manual option, the account timezone and integrations starting date set during configuration, the email sync report option, and the instruction to install an additional plugin so the connector can read custom order statuses. Two further Intuit pages on managing syncs and troubleshooting errors could not be opened, so no claim is made here about where sync errors are surfaced in that product.
• QB Connector and Shopify Connector not syncing purchases - QuickBooks community, October 2023 to February 2025, read 8 September 2026. Products and customers syncing while sales and purchases showed zero, the vendor's answer that QuickBooks only receives data and does not control the sending side, and the workaround a community member found by switching between detail and summary mode. This concerns QuickBooks Desktop and Shopify rather than the WooCommerce pairing discussed above.
• MyWorks pricing and Octopus Bridge RetailEdge integration pricing - read 8 September 2026. Tier prices, order limits and sync frequencies — the MyWorks figures read with the Shopify and QuickBooks Online pairing selected. What these pages do not state, either way, is whether the products display a count of records delivered.