Scaling

A spreadsheet column layout that scales from 100 to 10,000 orders

May 1, 2026 · 8 min read

Key takeaways

A sheet scales when columns are treated as a fixed contract and rows are append-only — never move a column once automation writes to it by position.
Group columns into three contiguous zones: identity, tracking, and money, so both the automation and the human reader always know where to look.
Keep one value per cell, map AliExpress's many raw strings to a small set of canonical statuses, and store the carrier as a resolved value from the tracking-ID prefix.
Avoid merged cells and free-text columns wedged between data; they are the most common cause of broken programmatic writes.
Fetch Order Tracking writes into your existing Google Sheet using this stable layout and respects terminal statuses, so the working set stays small even at 10,000 orders.

Almost every dropshipping spreadsheet starts the same way: a few columns, added one at a time, in whatever order the problem showed up. That layout works beautifully at 100 orders. At 1,000 it gets clumsy. At 10,000 it actively fights you — formulas break, automation writes to the wrong place, and you spend more time fixing the sheet than reading it.

The fix is not a fancier tool. It is a column layout designed up front for two readers at once: the automation that writes to it and the human who scans it. Get the layout right and the same sheet carries you from your first order to your ten-thousandth without a rebuild.

The core principle: stable columns, append-only rows

The single rule that makes a sheet scale is this: columns are a contract, rows are data. Once a column exists at a fixed position with a fixed meaning, you never move it and never repurpose it. Automation writes to columns by position, so the moment you insert a column in the middle, every write lands one cell off and your data quietly corrupts.

The most expensive spreadsheet mistake is moving a column after automation depends on it. Decide the layout once, then only ever append.

Rows, on the other hand, are append-only. New orders go at the bottom. You never re-sort the source data in place, because re-sorting is how you lose track of which row the automation last touched.

The columns that earn their place

Here is a layout that holds up at volume. Group it into three zones — identity, tracking, and money — and keep each zone contiguous:

Identity: eBay order ID, AliExpress order ID(s), SKU, store/region. These never change after the order is created.
Tracking: tracking ID, resolved carrier, tracking status, estimated delivery date (EDD), delivery-proof link, AE order date.
Money: AE order amount, eBay net earnings (the real payout, not gross), refund state.

Notice what is not here: no free-text "notes" column wedged between data columns, no manually colored status cells that automation cannot read, no merged cells anywhere. Merged cells are the number-one killer of programmatic writes.

Design for the machine, then for the eye

A sheet that scales has to be writable by automation without ambiguity, and readable by you at a glance. Those two goals fight unless you separate them:

One value per cell. Status is a status, not "Delivered (but check)". If you need nuance, that is a second column.
Canonical statuses. Map AliExpress's dozen raw strings down to a small, fixed set your eye recognizes instantly.
Carrier as a resolved value, not whatever AE handed you. The real courier comes from the tracking-ID prefix, which is exactly the argument in why you should never trust AliExpress's carrier_name field on its own.
Conditional formatting for the human layer. Color is for your eyes; the underlying value stays clean for the machine.

Keep the working set small

The thing that actually slows a sheet down at 10,000 rows is not the row count — it is re-processing rows that are already finished. A delivered, refunded, or cancelled order is terminal. It should never be fetched again.

So your layout needs a clean terminal-status concept that your automation respects with a skip-list. Active orders stay in the working set; terminal orders sit in the archive part of the sheet and get left alone. This keeps every run fast no matter how big the history grows. If your sync keeps grinding over the same rows, that is the missing piece, and we dug into it in why your auto-update keeps looping on the same 25 rows.

Where Fetch Order Tracking fits

You can build this layout by hand, and plenty of sellers do. The catch is that you then have to keep the automation, the column positions, and the status mapping all in sync forever. Fetch Order Tracking writes into the Google Sheet you already own using exactly this kind of stable, append-friendly layout — identity, tracking, and money columns populated automatically per order: tracking ID, resolved carrier, status, EDD, AE amount, refund state, proof link, and AE order date.

Because it pulls eBay net earnings from the Finances API rather than guessing fees off gross prices, the money zone is actually correct, not an estimate. And because it respects terminal statuses, the working set stays small even when your history runs into five figures. The sheet that got you to 100 orders is the same sheet that carries you to 10,000 — see how the full eBay × AliExpress sync keeps it that way.

The short version

Fix your columns; only ever append.
One value per cell, canonical statuses, resolved carriers.
No merged cells, no free-text wedged between data.
Keep terminal orders out of the working set.
Let automation own the writes so the layout stays consistent.

A spreadsheet does not fail at scale because it is a spreadsheet. It fails because it was never laid out for scale. Lay it out once, the right way, and it will keep up with you for a very long time.

Frequently asked questions

Why does my spreadsheet break when I add a column in the middle?

Because automation usually writes to columns by position, not by header name. The moment you insert a column in the middle, every write lands one cell to the side and your data quietly corrupts. The fix is to treat columns as a fixed contract: decide the layout once, never move or repurpose a column, and only ever append new columns at the end.

What columns should a dropshipping tracking sheet have?

Group them into three contiguous zones. Identity holds the eBay order ID, AliExpress order IDs, SKU, and store or region. Tracking holds the tracking ID, resolved carrier, status, estimated delivery date, delivery-proof link, and AE order date. Money holds the AE order amount, eBay net earnings from the Finances API, and the refund state. Keeping each zone together is what stays readable at volume.

What actually slows a sheet down at 10,000 orders?

It is rarely the raw row count — it is re-processing rows that are already finished. A delivered, refunded, or cancelled order is terminal and should never be fetched again. With a skip-list that excludes terminal statuses, active orders stay in the working set and finished orders sit in the archive, so each run stays fast no matter how large the history grows.

Related guides

Try Fetch Order Tracking → More guides