Inside an ASG fulfillment sorting area. By Janson Wang, Founder of ASG Dropshipping · September 29, 2026 · 19 min read
Someone edits row 214 while you’re still reading row 214. The tracking number you pasted in this morning doesn’t match what the customer got in their inbox. The stock count says 12. The supplier says 3.
None of that means your spreadsheet has failed. It means something else has quietly changed underneath it.
There’s no official order-count, SKU-count, revenue, or team-size number that tells you when to leave Google Sheets for an OMS or ERP — Google’s and Shopify’s own developer documentation don’t publish one.
What they do publish is a set of behavioral expectations for anything that manages orders: one system that’s authoritative, someone accountable for updating it, a way for Shopify to hear about changes automatically, and a scheduled check that catches the moment those two stop matching.
The question isn’t how many orders you’re processing — it’s whether every order still has all four.
The five operating controls used in this article’s diagnostic framework. Your spreadsheet still works. That’s exactly why this is hard to see.
Two teammates edit the same row within a minute of each other. A tracking number gets typed into the wrong cell.
None of that is proof your process is broken — it’s a set of symptoms, and symptoms need a diagnosis, not a verdict.
Before running these checks, pin down three things: which system is authoritative for this data, where changes are actually allowed to be written, and which direction updates flow.
Those three decide whether your spreadsheet is meant to be a view or the working record — a decision your team made, or drifted into.
What the checks below test is whether the controls around that decision are actually in place.
That question splits into five smaller ones.
Shopify’s own developer documentation — the parts that define how any third-party system is allowed to plug into order and fulfillment data — answers a version of all five, without ever mentioning a number of orders.
The Five-Question Test: ASG’s Control Checklist for a Shopify Spreadsheet
#
Ask yourself
What “no” looks like
How you tell
1. Authoritative source
When the sheet and Shopify disagree on an order’s status, which one is supposed to win?
Nobody can say — or the answer changes depending on who you ask
Find one field where the two have disagreed before, and confirm in writing which record is supposed to win for it
2. Declared ownership
Is it written down anywhere who updates this order’s status next, or does everyone just assume someone will?
Two people each think it’s the other’s row to update
Ask three teammates who owns updating in-transit orders — if you get three different answers, it’s not declared
3. Event-driven writeback
When the status changes, does anything actually happen, or does it just sit in a cell?
The cell changes; nothing downstream reacts to it
Using a test order, change its status in the sheet and watch whether Shopify’s own order timeline reflects it, or only the sheet does
4. Exception surfacing
Does a stuck order raise a flag on its own, or does someone have to go looking — or wait for the customer to ask?
The first sign of a problem is a support ticket
Count how many of your last ten “surprise” tickets were already sitting, unflagged, in the sheet
5. Reconciliation cadence
Is there a routine where someone checks the sheet against Shopify’s real numbers, or only when something already looks wrong?
The only “reconciliation” is a panic after a stockout
Ask when the last scheduled — not triggered-by-a-problem — stock check happened
Answer each one “yes, and here’s how,” “no,” “not applicable,” or “not enough evidence to say” — the last two are legitimate answers, not a dodge: a question that doesn’t fit your setup isn’t the same as a “no.” Answer all five with a confident “yes,” and the controls around this spreadsheet are doing their job, whether it’s a view or the working record.
One or more “no”s is a specific, fixable control gap — not proof the whole approach has failed, and not something a volume number would have predicted.
Notice what’s missing from that list: a column for order count. None of the five questions asks how big the business is.
They ask whether specific, checkable habits exist.
That’s deliberate, and it’s also the reason the rest of this article keeps coming back to this table instead of to a growth chart — the five questions are what the rest of the evidence below actually supports, not a framework invented to sound tidy.
Map your order data before you pick a tool.
ASG can walk your fulfillment and supply-chain data through these five questions with you — no system sale attached.
Talk to ASG About Your Order Data
Use operating controls to decide when a spreadsheet has become a shadow system. A spreadsheet that drifts from Shopify is not a growth problem. It’s an ownership-and-writeback problem that shows up sooner in some stores than others.
That’s worth saying plainly, because “how many orders before I need an OMS” is one of the most common ways people frame this decision — and it’s the wrong frame.
We read five pieces of official documentation that between them cover Google Sheets’ own API limits, how Shopify displays tracking to customers, how third-party fulfillment systems are meant to write data back to Shopify, and how an enterprise-grade order management system (OMS) is expected to stay in sync with Shopify.
None of the five gives a number of orders, SKUs, revenue, or team size as the point where you’re supposed to switch.
That’s a specific, bounded claim: these five official reference documents don’t publish a threshold — not that Shopify or Google have never, anywhere, suggested a rough scale at which spreadsheets get unwieldy.
We didn’t search their full blog and marketing archives.
What Shopify’s guide for building an enterprise OMS integration does publish is a description of how a system is expected to behave once it’s handling fulfillment: query the full order after every webhook, poll periodically to catch anything missed, write status back so customers and support can see it, and reconcile against Shopify’s numbers on a schedule.
Every one of those is about behavior, not about how big your business has gotten.
This article is narrower than “why fulfillment gets harder as a Shopify store grows” — that broader set of pressure points has its own separate piece, why fulfillment breaks when Shopify orders start growing .
Here, the focus stays on one specific fork in the road: whether the record-keeping tool itself — Sheets or something else — is still safe to trust.
Published API limits describe request behavior, not a mandatory business-size cutoff. Google’s own Sheets API documentation is worth reading directly, because the numbers in it get misquoted as “how much a spreadsheet can handle” when they’re actually about something narrower: how fast, and how large, a single API call is allowed to be.
The documentation states plainly that there’s no hard size limit for a single request — Google recommends staying under a 2MB payload for speed, but that’s a performance suggestion, not a ceiling.
The rate limits are per project and per user, per minute: 300 read and 300 write requests per minute per project, with each individual user capped at 60 reads and 60 writes per minute within that same project.
Any single request that runs longer than 180 seconds times out. And — this is the part most people miss — as Google puts it:
“Provided that you stay within the per-minute quotas, there’s no limit to the number of requests that you can make per day.”
Read that again next to the “how many orders before Sheets breaks” question. There isn’t a daily order ceiling baked into the API — but that doesn’t mean order volume never matters.
The constraint is a per-minute call frequency and payload ceiling, not a daily total one.
A store doing 40 orders a day and one doing 4,000 can both stay inside 300 requests a minute as long as the workflow — opening the sheet, glancing at a row, typing an update — never calls the API at all.
But once something automated reads or writes that sheet on a schedule, peak call volume, operations per order, batching, file size, and queued writes all become real constraints against those same per-minute quotas and the 180-second timeout — not a silent pass.
None of the five official documents reviewed for this article name an order-count, SKU-count, revenue, or team-size threshold tied to these limits — that’s the specific, bounded claim this article makes, not a claim that capacity never matters.
What actually strains under order volume is both the five things from the table above and , once automation is calling the API on a schedule, these quota mechanics: more conflicting edits, more updates to write, more exceptions to catch, more calls competing for the same per-minute allowance.
Volume makes both kinds of gaps more frequent; it doesn’t create either on its own.
A store with zero ownership and zero reconciliation has the same blind spot at 15 orders a day as at 1,500 — it just takes longer to notice, and longer to hit a rate limit by hand.
A correct row can still leave Shopify and the customer view outdated. Here’s a scenario worth sitting with: an order is marked fulfilled, but Shopify’s own admin has no carrier name and no tracking number attached to it.
That gap isn’t automatically a problem — Shopify’s own documentation ties automatic tracking entirely to whether the fulfillment service you’re using actually sends that information to Shopify; if it doesn’t, the field stays blank whether or not anything is actually wrong.
The question is what Shopify recommends when the gap looks like an actual stall.
Shopify’s order-tracking help documentation gives a specific answer for that case:
“If a fulfilled order has no carrier and no tracking number, or has a status of Requested, then the order might be with a third-party fulfillment app for processing.
Contact that app’s support for the tracking information.”
Notice the word might .
Shopify isn’t ranking causes or giving odds — it’s naming one possibility and pointing to the one channel it can reliably suggest: ask the app that’s supposed to be handling it.
That fix is manual, documented as such.
This article isn’t claiming to know whether some other automated escalation exists elsewhere for this exact symptom — only that this is the guidance Shopify publishes.
This is the fourth question from the table above — exception surfacing — made concrete.
If an order sits in your spreadsheet with a tracking cell that should be filled and isn’t, and nothing is scanning for that on a schedule, the order doesn’t raise a hand on its own.
It waits, and the customer may end up noticing first — checking a status page that reflects whatever Shopify last actually recorded, not necessarily what’s happening in your warehouse.
A spreadsheet, on its own, sends nothing to Shopify — someone has to build that bridge, or the order stays invisible from Shopify’s point of view no matter how current the spreadsheet looks.
Each handoff needs a declared owner and a visible output. The second diagnostic question — declared ownership — has a direct technical parallel in how Shopify defines a third-party fulfillment service.
Shopify’s FulfillmentService object documentation
“A Fulfillment Service is a third party warehouse that prepares and ships orders on behalf of the store owner.”
That object exposes two boolean fields — inventoryManagement and trackingSupport — and they’re not cosmetic.
When trackingSupport is true and the service has a registered callback URL, Shopify sends GET requests to that endpoint asking for tracking numbers; inventoryManagement works the same way for stock levels.
A registered service can also skip waiting and proactively push tracking updates itself, using the mutation described later in this article.
Either way, these flags describe what data a service is expected to supply — they don’t assign a human being to build that integration, keep it running, or notice when it stops working.
Someone still has to own that.
A spreadsheet has no equivalent field for declaring which service — or which person — is responsible for a given order’s tracking data.
That assignment, if it exists at all, usually lives in someone’s memory, a Slack message from three weeks ago, or an unwritten habit of “whoever’s online first.” None of those are wrong exactly, but none of them are a system Shopify can query, and none are visible to a new hire on day one.
Spreadsheets being informal isn’t really the gap.
The real gap is that Shopify’s integration model assumes ownership is declared somewhere a system can check — and a spreadsheet, by itself, has nowhere to declare it in a way Shopify recognizes.
Structured events move fulfillment truth into Shopify. This is the piece that separates a spreadsheet used as a view from a spreadsheet quietly running as the system of record: does a status change in the sheet ever actually travel back to Shopify, or does it just sit in the cell where you typed it?
Shopify’s Admin GraphQL API documents a specific mutation for exactly this purpose . fulfillmentTrackingInfoUpdate, in Shopify’s own words:
“Updates tracking information for a fulfillment, including the carrier name, tracking numbers, and tracking URLs.”
It’s worth being precise about what this call does and doesn’t do: it updates the carrier, tracking numbers, and tracking URLs on a fulfillment that already exists.
It isn’t a general-purpose order-status API — it doesn’t create a fulfillment, and it isn’t how a delivery event gets recorded.
This article verified this one mutation; where an order’s broader status comes from — created, fulfilled, delivered — is Shopify’s own internal bookkeeping, not something a single tracking-update call stands in for.
It supports single or multiple tracking numbers for shipments split across packages, and it accepts a notifyCustomer argument that controls whether the customer gets an update — Shopify states plainly that “if this field is left blank, then notifications won’t be sent.” That’s a real, structured, documented call, not a note in the margin.
It changes what Shopify — and therefore the customer and your own support team — actually sees for that fulfillment’s tracking fields.
The FulfillmentService object pairs with this: a registered service can proactively call that same mutation rather than waiting for Shopify to ask, and it can subscribe to fulfillment-order and order webhooks to hear about changes on a near-real-time basis rather than only when polled.
Shopify doesn’t treat that as a guarantee, though — webhook delivery isn’t promised to be complete or delay-free, which is why the same guidance (covered next) also calls for periodic polling and reconciliation as a backstop, not an optional extra.
The Writeback Most Spreadsheet Workflows Never Build
Mechanism
What it does
Where it’s defined
fulfillmentTrackingInfoUpdate mutationWrites carrier name, tracking number(s), and tracking URL(s) back to an existing fulfillment; can notify the customer
Shopify Admin GraphQL API
Two boolean flags on the fulfillment service record
Tell Shopify which registered service to ask for tracking data, and which to ask for stock data
FulfillmentService object
Fulfillment order / order webhooks
Lets a registered service hear about order and fulfillment changes on a near-real-time basis — not a replacement for periodic polling and reconciliation
FulfillmentService object
Typing “shipped — 9/15” into a spreadsheet cell doesn’t do any of this. It’s a note to yourself, not a call to Shopify.
Unless something else — a script, a connector, a person manually re-entering the same update into Shopify’s own admin — actually performs an equivalent action, that update lives only in the sheet.
Shopify’s order status page, the Shop app, and the customer’s inbox keep showing whatever Shopify last heard, which might be nothing at all.
If you sell through more than one supplier, this same writeback gap is also the root of a problem we’ve written about separately: why tracking numbers look inconsistent to Shopify customers when multiple suppliers are involved .
That article looks at what customers see once tracking data is fragmented across suppliers; this one stays on the narrower question of whether anything writes that data back to Shopify at all.
A real ASG packing and dispatch station. Shopify’s guide for building an enterprise-grade order management integration states something worth quoting in full, because it names exactly who gets hurt when writeback doesn’t happen:
“Customer-facing features such as Shop Pay, the Shop app, transactional emails, customer account order status pages, and order tracking links all derive their shipping and delivery information exclusively from Shopify’s fulfillment data.”
That’s a strong word — exclusively , not “mostly.” Every customer-facing surface Shopify controls pulls from Shopify’s own fulfillment data, full stop.
If the system actually handling the order — a formal OMS or an informal spreadsheet workflow — never writes its status back into that data, none of those surfaces will ever reflect it.
The order can be packed, labeled, and on a truck, and Shopify’s own admin will still show it as unfulfilled, because nothing told Shopify otherwise.
The same guide draws out the consequence directly: if the system fulfilling an order doesn’t write that status back, “the customer sees no shipping update and support teams can’t determine order status from the Shopify admin.” That’s your own support team, mid-conversation with a worried customer, opening the Shopify order and finding it blank — not because nothing happened, but because it never made the trip back into Shopify.
This is why the framing here keeps circling back to writeback instead of volume.
A ten-order-a-day store that never writes tracking back to Shopify has exactly this problem, just with fewer customers noticing it.
Shopify’s guide documents three patterns for architecting this — an external OMS as orchestrator, a hybrid model, and a Shopify-native pattern — and each one, regardless of which system holds the “truth,” still has to solve writeback.
Reconciliation turns mismatch into a logged correction instead of a customer surprise. Here’s a detail that should recalibrate how safe a spreadsheet workflow feels: Shopify’s guidance for building a fully automated , API-connected order management system still requires a recurring reconciliation job — not a one-time setup step.
In Shopify’s own words, under a section it calls cleanup reconciliation:
“On a daily or more frequent basis, run a reconciliation job that reads inventory quantities from Shopify, compares them against the OMS’s current state, and corrects any drift.”
Notice the scope: inventory quantities , specifically, inside an architecture where an external OMS is already orchestrating.
This is Shopify’s minimum bar for that pattern — a system that already has automatic webhooks and structured API writeback is still expected to check its inventory numbers against Shopify’s at least once a day, because drift happens regardless of how automated the pipeline is.
Shopify’s guidance doesn’t extend this specific daily-inventory-reconciliation requirement to every OMS, every data type, or to spreadsheet workflows — that extension is this article’s own operating recommendation, not something Shopify’s documentation mandates for a spreadsheet.
Applying that discipline earlier is still worth doing.
A typical spreadsheet workflow’s reconciliation often isn’t scheduled at all — it happens reactively, after a customer complains about stock that isn’t there, or someone notices a shipped order still marked pending three weeks later.
If Shopify’s own bar for a fully automated OMS’s inventory sync is “check daily, no matter what,” a spreadsheet with no writeback and no reconciliation of any kind has less of a safety net than the baseline Shopify sets for automation — not because Shopify requires spreadsheets to reconcile daily, but because the same drift doesn’t stop existing just because the workflow is manual.
Reconciliation: The Check That Even Fully-Automated Systems Still Need
Before migration (spreadsheet-only)
During migration (parallel run)
What gets checked
Whatever prompts a look — usually a complaint
Every record, on a fixed schedule, against Shopify’s numbers
Who checks it
Whoever notices something looks off
A named owner, on a calendar
What “drift” means here
Discovered after the fact, often by the customer
Has a real chance of being caught and corrected before it reaches the customer
What it costs to skip
A support ticket, a refund, a trust hit
A failed cutover, traced back to whichever record wasn’t checked
None of this is a specific migration playbook, and it isn’t Shopify requiring spreadsheets to match an OMS’s cadence — it’s ASG’s recommendation to borrow the same reconciliation discipline Shopify expects for automated inventory sync, applied earlier, to whatever you’re running today, spreadsheet or not.
Process migration also requires shared training and clear operating ownership. ASG operating framework for a controlled spreadsheet-to-system migration. A “no” on one of the five questions doesn’t automatically mean the next step is buying a system.
Start with the cheaper option: if the gap is a missing owner, an unbuilt writeback, an unwatched exception, or an unscheduled reconciliation — and your current stack can support fixing it — repair the process first.
Only look at replacing the system of record when controls can’t be made reliable in that stack, or you’re hitting the capacity and integration limits described earlier.
Not sure which situation you’re in? Say so and gather more evidence — don’t treat one “no” as a mandate to buy an OMS or ERP.
If the evidence does point toward replacing the system of record, the sequence for moving off it is ordinary project-management practice, not a proprietary method — and it’s worth saying so plainly rather than dressing it up as more than it is.
Start by cleaning: work out which rows and fields are actually trustworthy versus guesses, duplicates, or stale.
This is usually more uncomfortable than it sounds, because it means admitting which parts of the “source of truth” haven’t actually been true for a while.
Then map: line up every field the sheet tracks against its equivalent in the system you’re moving to, and flag anything with no equivalent — those gaps are usually where the real decisions live.
Test with test orders, redacted replays, or a read-only comparison first — not live customer orders, since a fulfillment or inventory write can trigger a real notification or stock change the moment it touches production data.
Before a live parallel run, name one system as the writer for each data type (tracking, inventory, order status) so two systems aren’t both authoritative for the same field; define stable IDs matching a spreadsheet row to its new-system record; agree which business actions are allowed during the parallel period — customer notifications staying off until cutover; and write down what has to be true to call cutover complete, plus how to roll back if it isn’t.
Run both in parallel for a defined stretch, checking them against each other on the same reconciliation cadence described above.
Only then cut over on a schedule, rather than switching everything off in one move.
None of this is exotic — it’s the same sequence any system holding customer-facing data would need, just rarely written down for spreadsheets.
Where ASG fits into that sequence is narrower than “we’ll connect anything.” Our starting point is diagnosis: walking through the five questions above with a client’s actual order and fulfillment records to find where ownership, writeback, or reconciliation is missing — the same kind of diagnosis behind how growing stores manage multi-supplier fulfillment chaos .
From there, our role is to make the China-supply-chain side — sourcing status, QC records, shipment data — visible and usable inside whatever system a client has chosen, spreadsheet or otherwise.
We don’t promise to natively integrate with any specific ERP or OMS platform or protocol; that’s a capability we haven’t verified, and this article isn’t the place to claim it.
What we do is make sure the supply-chain data feeding into that decision is accurate before the migration starts.
Diagnose before you migrate.
If the five-question test above turned up more “no”s than you expected, ASG can help you trace exactly where the ownership and writeback gaps sit — before you commit to a system.
Book a Fulfillment Data Diagnosis
What is the difference between using a spreadsheet as a view and using it as the system of record?
A view is a window onto data that stays current somewhere else — Shopify’s order object, here. A system of record is what a business has decided to trust as authoritative.
Which one your spreadsheet is isn’t something the checklist above decides — that’s a call about where authority and write access live.
The checklist only tests whether ownership, writeback, exception-handling, and reconciliation are in place around that choice.
A system-of-record sheet with all five controls can be safe; a read-only view isn’t a failure just because it was never meant to write back.
Does Google Sheets have a technical limit that forces a switch to an OMS or ERP?
These specific API limits don’t translate into one universal order-count threshold.
Google’s Sheets API sets rate limits — 300 read and 300 write requests per minute per project, 60 per minute per user within that project — plus a 180-second timeout, with no daily cap as long as you stay within those per-minute limits.
Those are call-frequency and payload limits, not a fixed ceiling on order volume — but an automated workflow can still run into them, depending on peak call volume, operations per order, batching, file size, and queued writes.
Is there an official order-count threshold for moving off Google Sheets?
Not in the five official Shopify and Google documents we reviewed for this article.
None of them names an order count, SKU count, revenue figure, or team size as the point where you’re expected to switch systems.
What they describe instead is a set of behavioral expectations — ownership, writeback, reconciliation — that apply regardless of scale.
What should I check before trusting a spreadsheet-tracked order is actually done?
Check whether the status you see in the sheet has actually been written back into Shopify — the order status page, the Shop app, and customer emails all pull exclusively from Shopify’s own fulfillment data.
A row that says “delivered” but was never written back doesn’t make Shopify’s record catch up to it — Shopify keeps showing whatever it last actually recorded, whether that’s unfulfilled, a bare “fulfilled” with no tracking, or something else.
That gap is exactly what’s worth checking for.
How do I tell whether a stuck order is a spreadsheet problem or a fulfillment-app problem?
Check Shopify’s admin directly, and rule out the ordinary explanation first: tracking only appears automatically if the fulfillment service you’re using actually sends it to Shopify, so a blank field alone isn’t proof of a stall.
If the gap still looks wrong, Shopify’s guidance says a fulfilled order with no carrier and no tracking number might still be sitting with a third-party fulfillment app — contact that app’s support, rather than assuming the spreadsheet is wrong.
Does order volume decide when to leave Google Sheets?
No. The five official Shopify and Google documents reviewed here describe operational behavior — ownership, writeback, reconciliation — not an order-count threshold.
What does Google’s own documentation say limits Sheets?
Per-minute API rate limits — 300 requests per project, 60 per user — and a 180-second per-request timeout, not a daily or total order ceiling, though an automated workflow can still run into these limits.
Who does Shopify treat as responsible for tracking and inventory updates?
Whichever service has trackingSupport or inventoryManagement set to true on its registered FulfillmentService object.
What happens if a fulfillment status is never written back to Shopify?
Customers see no shipping update, and support teams can’t determine order status from the Shopify admin, per Shopify’s own OMS integration guidance.
How often should inventory be reconciled against Shopify?
Daily or more often — that’s Shopify’s stated minimum for a fully automated OMS’s inventory sync.
Applying that cadence to a spreadsheet workflow is this article’s own recommendation, not a Shopify requirement for spreadsheets.
Key Takeaways
There is no official order-count, SKU-count, revenue, or team-size threshold for leaving Google Sheets — not in Google’s Sheets API documentation, and not in the three Shopify Developer Documentation pages or the Shopify Help Center page reviewed for this article ([S3] [S4] [S5] [S6] [S7]).
Google Sheets’ documented limits are per-minute, per-project and per-user API call quotas (300/60 requests) and a 180-second timeout, not a daily order ceiling — though an automated workflow can still run into them ([S3]).
Shopify’s own troubleshooting path for a stuck, untracked order is “contact that app’s support” — even Shopify’s platform defaults to a manual check, not an automated one ([S4]).
A status typed into a spreadsheet only becomes visible to customers and support if it’s actually written back to Shopify through a mechanism like the fulfillmentTrackingInfoUpdate mutation; otherwise every customer-facing surface keeps showing Shopify’s last known state ([S5] [S6] [S7]).
Shopify requires daily-or-more-frequent inventory reconciliation even from a fully automated OMS ([S7]) — applying that same discipline to a spreadsheet workflow with no scheduled reconciliation at all is this article’s recommendation, not a Shopify requirement for spreadsheets specifically.
The five Google and Shopify developer/help documents cited in this article ([S3]–[S7]) were reopened directly on September 29, 2026, and checked word-for-word against the passages quoted here, rather than relied on secondhand.
Keyword and SERP data ([S1] [S2]) came from a live DataForSEO pull the same day.
Because [S5], [S6], and [S7] are all published by Shopify Developer Documentation, they’re treated in this article as one consistent statement of Shopify’s technical approach, not as three independent confirmations of it.
This article does not cover Google Sheets’ concurrent-editing behavior, connector-permission failure modes, or the operational specifics of any single migration vendor’s process — those weren’t verified this round and aren’t repeated here as fact.
It also doesn’t cover EU/UK-specific regulatory signals or a logged-in Shopify admin walkthrough; neither was completed in this research round.
The keyword and search-competition figures referenced in this article’s methodology come from a DataForSEO pull on September 29, 2026.
Google and Shopify documentation quotes were verified against the live pages the same day.
ASG’s own positioning in this article — diagnosis first, then connecting China-side supply-chain data into a client’s chosen system — reflects an internal 2026-07 process snapshot and is not a claim about integrating with any specific OMS or ERP platform, protocol, or API.
If you came here looking for a number — an order count, a revenue line, a team size — the honest answer is that neither Google nor Shopify publishes one, in the documentation this article checked.
What they publish instead is a description of what a system managing your orders is supposed to do: speak with one voice everyone agrees is authoritative, have a named owner, write its changes back automatically, and get checked against reality on a schedule.
You can run that check this afternoon, without buying anything. Pull your last twenty orders.
For each one, ask the five questions above, and let “not applicable” or “not enough evidence yet” stand as honest answers where they fit.
Get a confident “yes, and here’s how” five times, and the controls around your spreadsheet are doing their job.
Get even one “no,” and you’ve found a specific, fixable gap — one that has nothing to do with order volume, and nothing that requires buying a system before you’ve tried repairing what you already have.
