A By Janson Wang , Founder and CEO of ASG Dropshipping, a China-based supply chain and fulfillment partner working out of Shenzhen and Dongguan | Written for China brands preparing to take a first overseas order
Editorial planning graphic; not evidence of a particular service provider’s capability. A customer in Germany adds one product to the cart. Your Shopify checkout shows a rate and a duty-paid option, so the order looks ready to take.
Both of those are your own settings. What the screen displays is configuration, and configuration on its own does not record whether anyone outside your company has confirmed anything.
You may already hold an email or a contract that does. The checkout screen is not where you find out.
The real question is not whether your store can display the option. It is whether anyone outside your company has confirmed they will deliver it.
So sort what you hold into three evidence classes and keep them apart.
Configuration is what your store displayed on a day. A scoped written confirmation records what a named party stated, and the limits they stated it within.
Observed execution records a real occurrence of the specific operation being checked, under stated conditions.
Cross border fulfillment is the work of getting that parcel to a buyer abroad and settling who pays what at the border. These three classes are not a definition of it — they are how this article suggests you record what you have checked.
Not every question needs all three. A configuration question is answered by configuration; carrier coverage is not.
One live shipment is evidence for the operations it actually covered — that product, that route, that date, those conditions.
Where the evidence is missing, write the gap down: who has not been asked, and what you do next.
Start with one product and one market, and fill the first two rows of the sheet below: who carries it, and who hands it over.
Key Takeaways
Configuration, a scoped written confirmation and an observed execution record are three classes of evidence, not three levels of certification. Match each question to the class it needs.
A written yes records what a named party stated and the scope they stated it within. Read the scope before you rely on it.
Every row carries its own scope. When something changes, re-check the rows that change touches.
Legal, product-compliance and channel-eligibility requirements are separate gates. Narrowing your shipping promise does not clear them.
For a row you could not confirm, narrow what you promise at checkout, or hold the listing.
Staff handling items and packaging at an ASG warehouse workbench. What follows is a minimum pre-launch fulfillment confirmation sheet. It is not a complete going-global checklist, and not a legal or channel admission checklist.
It covers four things: who carries this product on this route, who handles duties and import charges, what happens between order and carrier handover, and what happens when a parcel comes back.
Write the header once per arrangement. Give it a shared-scope ID so twenty SKUs travelling the same way can point at one record — as long as their restriction class, packaging, service and exceptions really are shared. Any SKU that differs gets its own line.
Cross Border Fulfillment Questions to Confirm Before Launch
Header field
What you write
Shared-scope ID
The label this record is filed under, and which SKUs point at it
Product or restriction class
The product, and whether it contains cells, liquids, magnets or anything else restricted
Parcel weight and dimensions
The range this record covers
Ship-from location
Where the stock physically sits
Executing party
Who picks, packs and hands over, named separately from the location
Destination market
The country, and the region within it where that matters
Channel and seller program
The channel, and the program your account lists under
Carrier and service level
Who books, who pays, and which named service
Integration
The app or connection passing order and declaration data
Volume and season
The order volume and period this record was answered for
Date and version
When you wrote it, and when it is due for review
One boundary, stated once here rather than repeated through the article. This sheet is a fulfillment planning tool I recommend as an operator, not a verified industry standard. A filled sheet says nothing about product safety, certification, seller-program admission, tax treatment or legal correctness — those are separate gates with separate owners, and dangerous-goods restrictions sit outside it entirely. Every platform mechanism below is Shopify only, as read in September 2026.
Now the propositions. Each row is one statement that can be confirmed or not, with one primary party who answers for it — the main respondent, not necessarily the only party involved.
Cross Border Fulfillment Questions to Confirm Before Launch
Row
Proposition to confirm
Primary party
Scope that limits this row
Do not publish until confirmed
A1
This carrier service carries this product class on this route
Carrier, named service
Ship-from, destination, product class, weight, dimensions
That the destination is served for this product
A2
This party will pick, pack and hand over these orders
Executing party
Stock location, product, period
That anything is handed over at all
B1
Who is recorded as importer of record
Your broker or adviser
Destination, trade structure
Any duty-paid outcome at checkout
B2
Who bears border charges under the commercial arrangement
Counterparty to that arrangement
The agreement and its period
Who absorbs the charge
B3
Who receives the carrier or broker invoice
Carrier or broker billing contact
Account, service, route
That a checkout payment settles it
B4
This carrier service supports DDP on this route
Carrier
Service, route, product
A duty-paid label
B5
The named integration transfers the specified fields to the named receiving system as documented
Integration provider
App version, store setup, field list
That the receiving system holds the fields it needs
B6
This duty-collection feature applies to your Shopify account and market setup
Shopify, for your account
Your account and market setup
That the feature is available to you
B7
The product data this feature relies on is complete and accurate
You
The SKUs in scope
That an estimate rests on correct product information
C1
The executing party confirms the processing steps, responsibilities and handling window for this scope
Executing party
Stock location, product
A processing window
C2
The executing party confirms the cutoff time, clock boundaries, time zone and applicable days
Executing party
The named arrangement
A cutoff time
C3
Which shipment-linked handover record will be produced, by whom, and how will it be retrieved
Executing party, with carrier
Named route and service
That handover evidence will exist for a shipment
D1
The named owner has approved the published policy version for this market
Named policy owner
The market it is published for
A returns promise
D2
The configured return rules have been checked against the published policy for this market
You
Your store
That policy and rules match
D3
Who physically receives a returned parcel
Return receiver
Destination, channel, period
A return address
D4
Who inspects and decides disposition
Disposition authority
The arrangement, per product
What happens to a returned unit
D5
Who can authorise a refund, and what event triggers it
Payment-side approver
Channel and payment method
A refund path
One company can answer for several rows. Record the roles separately anyway, because a yes given for D3 says nothing about D4.
The store-side question — whether a customer in that market can order and see a rate — is a configuration self-check with its own table below.
For row A1, Shopify’s international shipping page tells merchants to check carrier availability and third-party fulfillment capability for the destination, as read in September 2026.
Every row then takes the same fields, because one status word cannot carry three different conclusions.
Cross Border Fulfillment Questions to Confirm Before Launch
Field
What you write
Proposition
The single statement this record is about
Applicable scope
Whichever of ship-from, destination, product class, weight and dimensions, carrier service, integration, volume and season apply
Answering party
One primary name, plus anyone else consulted
Evidence class
Configuration, scoped written confirmation, or observed execution
Evidence source, date and link
Where each record lives and when it was made — a row can carry more than one
What it proves
The narrowest true reading of that record
What it does not prove
Written out, not left implied
External validity
An expiry or review date the counterparty itself stated
Internal review date and trigger
Yours, marked as yours, plus the events forcing a re-check
Confirmation status
Not asked, Waiting, Unclear, Declined, Confirmed, Confirmed with exceptions
Execution status
Not tested, Dry run passed, Live-tested, Failed test
Validity status
Current, Expired, Superseded, Not applicable
Open item and next action
What is unresolved, and whose name is on it
Two of those fields do most of the work.
A screenshot of your own admin settings is configuration evidence. It records what your account displayed on a day, so it belongs under Evidence class: configuration.
A screenshot of something else — an email, a handover record — is classified by what it shows, not by the fact that it is a screenshot.
A date you set yourself is an internal review date. It does not extend the validity of a quote or a confirmation the other side put its own expiry on.
Confirmation, execution and validity are three separate statuses, which is the point: a row can be Confirmed and Not tested at the same time. If you use Expired, Superseded or Not applicable, write down what you are relying on to say so.
Four more items belong in the record as questions, not conclusions: which clauses apply, what the exceptions are, who you escalate to, and who carries the cost. Write those four down and a lawyer has something to read.
Checking the warehouse itself is a different job — that one is the China 3PL warehouse checklist to work through before moving inventory .
Filling this in locks you into nothing, and changing something later does not void the sheet.
Each row states its own scope. When something changes, you re-check the rows that change touches and the rest stands.
Three cases show how that works. All three are illustrative teaching examples, not ASG customers, with no amounts and no brand names.
Illustrative case one. A carrier replies that Germany is fine, but a SKU containing cells needs a separate assessment.
That lands on row A1. Scope: Germany yes, cell-containing SKU pending. Confirmation: Confirmed with exceptions; execution: Not tested. Open item: the cell assessment, with dangerous-goods restrictions confirmed separately.
The German answer is real and it stays. It just does not reach the SKU still being assessed.
Illustrative case two. A 3PL writes by email that it can receive returns, peak season excepted.
That lands on row D3, and only on D3. Scope: peak season excepted. Confirmation: Confirmed with exceptions; execution: Not tested.
Nothing lands on D4 or D5, because taking a parcel back is not the same as deciding what happens to it or releasing the money.
My take on this one: the re-check date matters more than the yes. An exception with no date attached becomes a surprise in your busiest month.
Illustrative case three. The market is active, rates appear in the zone, and nobody outside your company has been asked anything.
That lands on the configuration self-check only. Rows A1 and A2 stay at Not asked, and the next action reads: no carrier and no executing party approached yet.
One more distinction, because it decides how the header gets filled. China direct, third-party fulfillment and overseas stock are not three exclusive options on one axis — a 3PL in China can ship direct too.
Where stock sits, who executes, what transport is used, and on what terms costs land are four separate cells.
A confirmation for one SKU covers exactly that row. Mixed carts, split parcels, restock cadence and a peak-season spike are separate propositions.
Illustrative worksheet structure. Its fields organize evidence; they do not certify capability or compliance. A setting in your admin proves what you set on your side. It is the cheapest evidence you can produce, which is why it gets mistaken for agreement.
On its shipping rates page , as of September 2026, Shopify writes: “Customers in inactive markets can’t place orders even when their country is in a shipping zone with available rates.”
Two separate preconditions, and one does not deliver the other. That page also notes stores moving toward managing shipping options by market, so I would not assume every store sees an identical screen.
The international shipping page , as of September 2026, says: “You might need to make changes to your shipping settings to make sure the shipping options that you offer to customers are actually possible.”
Read that as an instruction about your own settings, not a statement about your route.
Each page supports its own point and is cited where it applies. All come from one publisher, so they do not corroborate one another, and none of it extends to TikTok Shop or Amazon.
What a Shopify Setting Proves and What It Does Not
What you see in the admin
What it proves
What it does not prove
Who confirms the rest
The market is active
Market status is not blocking orders in that country
That anyone agreed to carry a parcel there
Carrier and executing party, per destination
Rates appear for the zone
A price is shown for that zone
That the service behind it runs for this product
Carrier, for this destination and product
A shipping option shows at checkout
The option exists in your settings
That it is deliverable as offered
Carrier and executing party, by destination
A screenshot of any of these admin screens
What your admin displayed that day
That anyone outside your company saw it or agreed
The party you have not written to yet
An active market is not a statement that the requirements for selling that product there have been met. Compliance, certification and channel eligibility are confirmed separately, by their own owners.
So use the table for what it is good at: finding rows where your store already promises something nobody outside your company has confirmed.
Turning on duty collection puts a number in front of your customer. It does not put a carrier behind that number.
Shopify’s page on collecting duties at checkout , as of September 2026, tells merchants: “Confirm that your shipping carriers and third-party integrations support delivered duty paid (DDP).” That page also describes the amounts as estimates depending on the product information you supply.
So the checkout setting is the last step here, not the first. Rows B1 to B7 sit ahead of it, and each needs a named accountable role — the same company may hold more than one.
Who is recorded as importer of record, and who files. Who bears duties and import taxes under your commercial arrangement. Whose name goes on the carrier or broker invoice.
Whether your carrier service supports duty-paid shipments on this route, which is row B4. Whether your integration transfers the specified fields to the named receiving system as documented, which is row B5.
What is finally declared is checked at the receiving end, not with the integration provider.
Whether the feature applies to your Shopify account and market setup at all. And whether the product data it rests on is complete and accurate, which is your row to answer rather than the platform’s.
Do not infer a plan threshold from that page. Check the current requirements for this specific feature in your own account.
The billing question is the one people merge. Bearing a cost and receiving the invoice are two answers, and a customs broker can be a third party in the chain. Ask separately, in writing.
Merchants raise this out loud. In a 2024 thread, a Shopify Community poster asked whether upgrading the plan and changing the label billing settings would make import fees bill to the merchant, and went on:
“do I have to somehow register for duty remittance in every country?”
— NimbleRobot, Shopify Community, 2024-09-23
That is the question, not the replies under it. Whether you register for anything in a destination country is a matter for someone qualified there.
A second thread shows the setup problem from the other side. A named merchant reported that a customer picked a cheap international service at checkout, and:
“Yet they also were able to select ‘prepaid duties’.”
— user2800, Shopify Community, 2025-06-04
Two options offered side by side in one checkout. That is the pattern to look for in your own store: a duty-paid promise sitting next to a service nobody has confirmed can carry it.
Both threads come from the same community. They establish that two named merchants raised this, and nothing wider.
A desk walkthrough before launch is still worth doing. Trace where the duty is calculated, who receives the bill, and which service moves the parcel, then record it as Dry run passed.
A live order provides execution evidence only for the events actually checked. Attach each observation to the relevant B row; do not treat completion of the shipment as validation of every role, eligibility condition or product-data judgment.
A completed shipment does not settle legal roles, product classification or origin, everything else in your account, or the orders that come after it. Not every B row needs a live test.
For what DDP means as Shopify implements it, the duties page linked above is the reference. The confirmations are still yours to collect.
Sorting bins, carts and workstations in an ASG warehouse dispatch area. Three different objects, and they do not sit on the same layer.
The fulfillment time page in Shopify’s Help Center, as of September 2026, draws its line at the handover: “Orders that require shipping are considered fulfilled when the business gives the shipment to a shipping carrier service.” That page also notes the steps before that point differ from product to product.
That page defines a fulfillment window. It is not describing how every app, API or warehouse integration writes a status into your admin, and I have not tested those mechanisms.
What follows is my own operating inference, and I would still act on it. An order marked fulfilled, and a label with a tracking number, each record that someone in your workflow performed an action. Neither on its own shows a carrier took custody.
So keep four artifacts separate: label created, admin status changed, carrier acceptance scan, and a signed manifest or pickup record.
Ask the executing party who sets the status and what triggers it. Then get four more answers before you publish a number.
Where the clock starts and where it stops. Order placed, payment cleared, or picked? Ends at pack complete, or at handover?
Whose time zone the cutoff runs on. An afternoon cutoff means two different things to a warehouse in China and a customer in Germany.
Business days or calendar days, and whether weekends count.
And what happens on holidays. For a China-based sender that means Chinese New Year, a planning conversation you have months ahead.
Now the layers. Your order handling window belongs to you and your executing party, with a start point, an end point, a time zone and a named owner.
The carrier transit estimate belongs to the carrier, with a named service, a route and its exclusions. The delivery window your customer reads is something you publish.
That third one is not a third addable interval. Where the handling window and the transit estimate share consistent start points, end points and conditions, you can combine them into a customer-facing estimate.
It stays an estimate rather than a guarantee, and you answer for the wording you publish, whoever else’s numbers went into it.
Before launch, confirm the handover-evidence method: which record will be produced, by whom, and how you retrieve it. After a shipment runs, record whether the promised evidence was actually produced and what it shows.
Row C3 can sit at Confirmed for the method while execution stays Not tested. A missing first-order record is not by itself a reason to hold the first order.
Keep the handling window, the carrier transit estimate and the delivery promise you publish as three separate records. A handover record settles none of them.
Wrapped items in warehouse staging crates. This photograph is not evidence of a returns-processing service. Five accountable functions. One party may own more than one, and none of them switches the others on.
The Shopify page on return and cancellation rules , as of September 2026, is explicit about one gap: “The generated policy doesn’t automatically include the return rules that you set up.” That page also describes an applicable return fee as something not automatically taken out of the refund.
That is Shopify, and that is the scope of that page. It is also the shape of the wider problem.
Shopify Return Rules vs Return Policy, Parcel and Money
Function
Who answers for it
What it does not automatically carry
How you check
Row
Published return policy the customer reads
You, and whoever drafted the text
The rules configured in your admin
Read the published text against your configuration, line by line
D1
Return rules configured in the admin
You
A matching published policy, or a fee actually deducted
Open the settings, compare them with the text, and record any difference you find
D2
Physical receipt of the parcel
Whoever receives parcels at the return address
Any decision about what happens next
Ask who signs for it and where it is held
D3
Inspection and disposition
Whoever is authorised to decide the item’s outcome
Authority to release money
Ask who inspects, who decides, and what the outcomes are
D4
The refund
Whoever can issue it on the payment side
A parcel arriving, or a fee coming off the amount
Ask who performs it, on what trigger, and whether a fee is deducted by hand
D5
The same company may answer for D3, D4 and D5. Write all three names down anyway. If you cannot fill in all three, that is a gap, not a formality.
Same with the item. Do not assume a returned unit goes back on the shelf. Inspection, repackaging, disposal, return to the supplier, hold for a decision — each is an outcome somebody chooses, and each costs somebody something.
A refund can also happen with no parcel coming back at all. That case earns its own record: who approved it, on what evidence, and what became of the goods.
A return that actually runs produces execution evidence too — for the rows it touched, and not for the rest.
Whether import duty already paid on a returned item can be recovered is a real question, and not one this sheet answers. Ask your customs broker, or the customs authority in that market, who files what and by when.
Your customers’ statutory return rights exist independently of these five rows. Get that read where you sell.
Already selling and weighing a UK or EU move? Different exercise — see the fulfillment diagnosis before a UK or EU expansion .
Your sales channel is a counterparty, and its answers are not interchangeable with your carrier’s.
Two different things are at stake, and they fail differently.
The first is eligibility: whether your seller type, this product, this ship-from location and this seller program permit the listing at all. If that is unconfirmed, narrowing your shipping promise does not make the listing publishable.
It is a required condition. It is either met or it is not.
The second is the shipping promise. Once eligibility is confirmed, what you publish stays inside what your executing party and carrier have actually confirmed.
So ask which seller program covers you: your seller type, this product, and the place the parcel actually ships from. State all three, because an answer about one does not carry to the other two.
Ask what that program requires in writing — which delivery options, what standards attach to them, and where returns must be received.
Ask where that text lives, and how you can tell you are reading the version that applies to your account. A page found through search shows you a document, not your enrolment.
Ask who at the channel answers this, and what has to be re-confirmed when you add a market or change who ships.
The evidence does not have to be a staff member filling in your form. Official program terms, an enrolment shown inside your account, a support ticket, an account-specific notice or an actual test all count, as long as you record which one you have and what it covers.
A successful listing or order test records technical behavior; it does not substitute for evidence that the applicable seller-program requirements are met.
I have not verified what any channel requires of your seller type, product or ship-from location, so that row stays open until the channel’s own material fills it.
If you are already selling on that channel, the questions move downstream to performance and scale. This sheet is written for the stage before that.
There is a serious argument for spending nothing on fulfillment infrastructure until orders show up, and it is not a weak one.
Stord, a fulfillment provider writing about when to switch from cross-border shipping to local fulfillment , reads that move off signals including order volume, delivery speed expectations and per-order shipping cost.
That is a commercial provider’s view of its own market rather than independent research, and the same page also discusses inventory placement and running one system across locations.
The cost it warns about is real. Stock bought ahead of demand, warehouse space rented on a guess, a long contract signed by a brand that has not sold anything yet.
For a small team that is cash tied up in a bet nobody has tested. I would hold it too.
That is an argument worth taking, not because confirming can wait, but because investing can. Those are two different clocks.
Nothing on that page argues you should list before you know who carries the parcel and who receives it back. That was not the question it set out to answer.
So take the point about the warehouse and keep the sheet anyway. This sheet does not, by itself, require a new warehouse lease or inventory investment.
A first run is supposed to stay small. One product scope, one market, one channel, and the arrangement you already have.
Keep one shared record for products that travel the same way, and re-check the rows a change touches. That is the version of this work a two-person brand can carry.
Where it shows up is in what you promise. A narrow promise can be supported by what you have already confirmed.
A wide promise with nobody behind it is exposed on the first order, and a sheet is a cheaper place to find that out.
Once you do have sales data, the allocation question opens on its own terms: splitting SKUs between an overseas warehouse and China direct .
A completed sheet records what you asked, who answered, and what has actually run. Each entry supports what it contains, and no more.
It does not tell you the partner is any good, or the price fair. It does not clear your product for sale, settle certification, decide how your taxes should be handled, or establish that a channel will have you as a seller.
A completed sheet does not prove continuing, scaled, peak-season or out-of-scope capability.
Where a row holds a real test, that test reflects the conditions and sample of one run. One product, one route, one day.
Add a SKU, a market or a channel, or change who delivers or who takes returns, and re-check the rows that change touches. Not the whole sheet.
Two conclusions I would not draw from any of this.
First, that every row needs all three evidence classes. Decide row by row, by what a wrong answer costs you. Where it costs a lot, get more than an email; where it costs little, record Not tested and move on.
Second, that anything untested means you cannot sell. Untested does not block you automatically and does not clear you automatically — it is a decision you make with the scope written down.
What it never does is waive a legal, product-compliance or channel-eligibility requirement. Those are required conditions in their own right, and a low-cost risk assessment does not reach them.
The applicable mandatory requirements and the responsibilities needed to deliver the launch offer must be established. Optional, out-of-scope or additional live-testing items may remain open, with the limits and next actions recorded.
What I would push back on is a blank cell quietly turning into a confirmation somewhere between your sheet and your product page.
Everything here is a fulfillment planning view. It does not replace local legal, tax or product compliance advice, and the platform mechanics described come from Shopify documentation as it read in September 2026.
Quick Answers About Pre-Launch Fulfillment Checks
Does an active market mean I can ship there?
No. It means market status is not blocking orders in that country. Whether anyone will carry that product on that route is a separate confirmation.
Can a screenshot of my Shopify shipping settings prove that a partner confirmed fulfillment?
No. A settings screenshot is configuration evidence. A screenshot of an email or a handover record can carry confirmation or execution — classify by what it shows.
Do return rules apply automatically to my written policy?
No. Shopify says the generated policy does not automatically include your configured return rules. Compare the two line by line before you list.
Should I re-check every row when I add a market?
No. Re-check the rows that market touches: carrier coverage, duties, returns receipt. Rows scoped to something you did not change still stand.
Do I need a warehouse in the destination market before my first order?
Nothing on this sheet asks you to rent one. It asks who holds the stock, who picks and packs, who moves the parcel and who takes it back — named parties, not square metres.
A warehouse in the market answers some of that. A 3PL in China answers some. What does not answer it is a lease standing in for the names.
A carrier said yes by email. What is still missing before I promise it at checkout?
Read the email before assuming anything is missing. Check whether it names the product or restriction class, the ship-from and destination, the carrier service, the period, the volume and the exceptions.
Whatever it names is confirmed within that scope. Whatever it leaves out is what you ask about next.
A promise about future capability is not an execution record, whatever it arrives in.
If that email forwards a handover scan or tracking from a shipment that actually ran, classify the attachment on what it contains, not on the medium.
Absent that, the row sits at Confirmed with execution Not tested. Keep the listing promise inside the narrowest thing that yes covers.
My partner confirmed one SKU. Does that cover a mixed cart or a peak-season spike?
No, and this is where the method fails quietly. A confirmation covers the proposition it was given for, at the volume that was discussed.
Two products landing in one order is a different proposition. So is a shipment that splits, and a week at triple the volume.
Ask about each by name. Where nobody has looked, record Not tested and promise accordingly.
How should I combine handling time and carrier transit into a delivery estimate?
There is no single number to hand you, and the parts belong to different owners. What you can pin down is the shape.
Your order handling window belongs to whoever picks, packs and hands over. The transit estimate belongs to the carrier and its named service. The delivery window is what you publish, and you answer for it.
Ask what starts and stops your handling clock, then which service moves the parcel on this route. Combine the two only where their start points, end points and conditions line up, and keep the parts as separate cells.
These four questions, and the four quick answers above them, were written for this article rather than quoted from any seller. Their search volume is unknown.
Cross border fulfillment does not get safer because your store can display a rate. It gets manageable when configuration, a scoped written confirmation and an observed execution record stop being read as one another.
My side of this table is the China side — sourcing, quality, and getting parcels out of a building. As the person who runs that side, here is the judgment I will put my name to: the questions that hurt at launch are the ones nobody has been asked, and asking them costs far less than discovering them on a customer’s order.
You do not need every row confirmed to launch, provided the legal, product and channel requirements that apply to you are met. What you do need is to know which rows are not confirmed, and to keep what you promise inside the ones that are.
So do one thing today. Take one product, one market and one channel, and fill a single row until you hit a blank.
If you want a second pair of eyes on that blank, email me at janson@asgdropshipping.com with the row you got stuck on. Some blanks belong to your channel, your carrier or your broker rather than to us, and we will tell you so.
Official platform documentation
Community questions from named individual merchants, not platform, tax or legal authority
Commercial provider viewpoint, not independent research
This article cites no ASG internal data. No order counts, no delivery times, no customer cases and no internal audit results appear in it, because none were drawn on for this piece. The sheet, the tables and the illustrative cases are my own operating recommendations rather than measurement, and a photograph of stock on a shelf would not prove capability either. The platform mechanics come from the Shopify Help Center pages listed above, read in September 2026. This is a fulfillment planning view, not tax, customs or legal advice.
