The Real Cost of Spreadsheet-Based Merchandising Planning

The spreadsheet planning reality for apparel brands

The majority of apparel brands plan their merchandising in spreadsheets. This is not a criticism — for a brand at early stage with limited SKUs and a small team, spreadsheets are a reasonable tool. They're flexible, familiar, and have zero implementation cost.

The problem is not that brands use spreadsheets. The problem is that most brands continue using spreadsheets well past the point where the tool can support the complexity of the planning task. And the cost of staying on spreadsheets accumulates in ways that are difficult to see until the total is significant.

This guide identifies the specific structural risks of spreadsheet-based merchandising planning — how they manifest, when they become material, and what changes when a brand moves to a connected system.

The structural problem: three files, no connection

The most fundamental issue with spreadsheet-based apparel planning is architectural. A typical spreadsheet-based planning stack looks like this:

• →File 1: OTB model (financial targets, receipt budget by period)
• →File 2: Assortment plan (style selection, depth targets, attributes)
• →File 3: Buy plan (style × color × size × vendor × cost)

These three files are interdependent: the OTB constrains the assortment, the assortment drives the buy plan, and the buy plan determines the final OTB consumption. But they are not connected. Every change in one file requires a manual update to the others.

This means that at any given moment during the planning process, at least one of these files is likely to be out of sync with the others. Teams reconcile them periodically — before buy reviews, before PO submission — but between reconciliation points, decisions are being made against data that may be stale.

Risk 1: Version control failure

Spreadsheet planning in a team of more than one person produces version control problems. Multiple copies of the buy plan exist simultaneously. Changes made to one team member's version are not reflected in another's. The "master" file is unclear, and resolving conflicts requires someone to manually compare two versions — a process that takes time and still produces errors.

Version control failure has direct financial consequences:

• →A style that was removed from the assortment in one version may still appear in another, generating a PO for inventory that's not needed
• →Depth adjustments made to reflect OTB constraints may be overwritten by the prior version
• →Size curve changes made by the buyer may not be reflected in the file the planner is using to reconcile OTB

The size and scale of version control errors grow with team size and SKU count. At 50 SKUs with two people, the errors are manageable. At 500 SKUs with five people, they are not.

Risk 2: Formula error propagation

Excel and Google Sheets formulas introduce errors that propagate invisibly. A single incorrect cell reference in the OTB model — pointing to Q3 receipts instead of Q2 — produces an incorrect remaining OTB figure for every dependent cell. Because the formula looks correct and produces plausible numbers, the error is rarely caught until the data is cross-referenced against actuals.

VLOOKUP and INDEX-MATCH functions — standard tools in assortment and buy planning spreadsheets — are especially prone to this failure mode. A shifted column, an extra row, or a typo in the lookup key produces a silent mismatch that may go undetected through the entire buy process.

Risk 3: Reconciliation consumes planning time

In a disconnected spreadsheet stack, reconciliation is a recurring, manually-intensive task. Before every buy review — typically quarterly or bi-seasonally — someone must:

1. →Ensure the OTB file reflects the latest assortment decisions
2. →Ensure the buy plan reconciles to the OTB
3. →Ensure the assortment file reflects any buy plan adjustments made since the last reconciliation
4. →Verify that vendor minimums are reflected in the size-level buy quantities
5. →Confirm that on-order data from the ERP or PO tracking system is current

This reconciliation exercise can take days. During this time, the planning team is maintaining files — not doing planning. And after the reconciliation, the window of accuracy is short: the next change to any file starts the drift again.

Risk 4: Decision latency

Because reconciliation is a periodic event rather than a continuous process, apparel planning teams in spreadsheet environments operate with decision latency — the gap between when a change happens and when its financial implications are visible.

A style dropped from the assortment liberates OTB. But in a spreadsheet workflow, that OTB isn't visible until the next reconciliation. In the interim, the team may make buy decisions that would be different if they could see the updated OTB position.

Decision latency is most costly in fast-moving planning situations: when a vendor delivers late and receipts shift, when a style underperforms in early weeks and the team wants to reallocate OTB, or when a new account commitment changes the wholesale OTB position.

Risk 5: Stale data driving forward-looking decisions

Assortment decisions for the next season are made against sell-through data from the current or prior season. In a spreadsheet workflow, this data is typically a CSV export from an ERP, POS system, or Shopify — loaded into the spreadsheet at a point in time and not updated automatically.

This means the hindsight analysis that drives next season's buy is based on data that's as stale as the last export. A style that had a late-season breakthrough — selling through the residual inventory in the last weeks of the season — may still show a low sell-through rate in the planning spreadsheet if the data was exported before the close.

When spreadsheets fail by segment

Spreadsheets are not equally problematic across all brand sizes. The failure modes are predictable:

| Brand stage | Spreadsheet failure mode | |---|---| | Under $10M, under 200 SKUs | Works reasonably well with discipline | | $15M–$30M, 200–400 SKUs | Version control problems begin; reconciliation becomes expensive | | $30M–$80M, 400–800 SKUs | Interdependency failures become systemic; decision latency is material | | $80M+, 800+ SKUs | Spreadsheets are no longer viable as a primary planning tool |

The inflection point is typically around $20M–$30M in revenue or 300+ active SKUs — wherever the combination of team size, channel complexity, and SKU count exceeds what one person can hold in their head and reconcile manually.

What changes in a connected system

In a connected planning platform, OTB, assortment, and buy planning share a single data model. A change made in the assortment plan — removing a style, adjusting depth — is immediately reflected in the OTB and buy plan. There is no reconciliation step because there is no disconnection to reconcile.

The specific changes teams report:

• →Buy reviews start with accurate, current data — no pre-meeting reconciliation exercise
• →OTB position is visible at any point during the planning process, not only after reconciliation
• →Style drop and depth changes are reflected immediately across the workflow
• →On-order data from the ERP syncs automatically — no manual import

The planning team's time shifts from file maintenance to actual planning.

Related resources

• →Replace Spreadsheet Planning — Migration steps and timeline
• →vs Spreadsheets Comparison — Side-by-side capability comparison
• →Merchandising Planning Platform — How connected planning works in RetailNorthstar
• →OTB Planning Guide — The financial layer most affected by spreadsheet disconnection