Stage ERP Syncs in a Spreadsheet Before the First Write

Every company that operates a serious ERP eventually faces the same tension. The ERP is the system of record for products, pricing, suppliers, and inventory. It is also slow to change safely, because a single bad write can corrupt downstream purchasing, costing, and reporting.

The typical pattern is worse than it looks. A buyer updates a supplier catalog in the ERP directly. A pricing coordinator fixes a typo in another module. A procurement analyst imports a spreadsheet of new supplier SKUs. None of these edits are reviewed together, and none of them are reversible as a unit. When one write is wrong — a duplicated SKU, an overwritten price, a supplier ID pointing at the wrong vendor — the error propagates through purchase orders, cost calculations, and inventory valuations before anyone notices.

The operational cost is not the keystroke. It is the investigation. Someone has to trace which record changed, when it changed, who changed it, and what downstream documents consumed the bad value. In most ERPs that forensic work is manual, slow, and unreliable.

The root cause of most ERP data corruption is not carelessness. It is the absence of a review boundary between intent and effect.

When a user writes directly to the ERP, the intent and the effect are the same action. There is no moment where the change exists in a reviewable, reversible state before it becomes live. That single action conflates three things that should be separate:

The third failure is audit blindness. When changes flow directly into the ERP, the only record of why a change happened is whatever the user remembers or types into a notes field. Six weeks later, no one can reconstruct the decision. This makes reconciliation nearly impossible.

The pattern that addresses this is straightforward: route all intended ERP changes through an intermediate staging system, validate them there, and push only approved changes into production.

For many supplier catalog and master data workflows, Google Sheets is a surprisingly effective staging system. It is not the final destination — it is the review boundary where intent and effect are separated.

A typical implementation looks like this:

1. Extract current supplier and product data from the ERP into a staging sheet. This gives reviewers a baseline snapshot of what exists today.
2. Propose changes in the sheet. New SKUs, price updates, supplier reassignments, and inactive flags all live in clearly marked columns or tabs.
3. Validate the proposed changes. This includes both automated checks and human review.
4. Approve the reviewed changes, either row by row or as a batch.
5. Write the approved changes to the ERP through a controlled integration job that replays the sheet data as API calls.
6. Confirm the writes by reading the ERP back and comparing it to the approved sheet.

The spreadsheet is not the system of record. It is a staging area — a place where the full set of intended changes can be inspected as a unit before commitment.

Consider a supplier catalog team that manages thousands of SKUs across multiple vendors. Their weekly cycle might look like this.

The integration extracts the current catalog into a sheet called supplier_catalog_staging. Each row represents a product with its supplier, cost, price, and status. The team then works in an edits tab where every intended change is a row: the ERP record identifier, the field to change, the new value, and the reason.

What makes this useful is that the entire batch of changes is reviewable at once. A pricing analyst can filter for all rows where the cost changed by more than 5 percent and confirm each one. A procurement lead can review new supplier assignments before they go live. Because the changes sit in a shared sheet with comments, the review is collaborative and asynchronous — no one has to be in the same room or the same ERP session.

Before the write happens, an automated validation pass runs against the sheet. It checks the things that are cheap to check deterministically:

• Required fields are present
• Supplier IDs exist in the ERP
• SKUs are not duplicated
• Price and cost values are positive numbers
• Changes only target records that actually exist

Rows that fail validation are flagged and excluded from the batch. The team investigates those separately. This keeps the deterministic checks separate from the human judgment — the system handles what rules can handle, and people concentrate on the cases that need context.

The write itself is a controlled job. The integration reads the approved rows, maps each one to the correct ERP endpoint, and executes the updates. The job is idempotent: if a write fails partway, re-running it only applies changes that have not yet landed, rather than duplicating work.

The value of this pattern shows up in operational signals, not in the spreadsheet itself.

Discrepancies surface before they corrupt production. The whole point of staging is that a wrong intended change is caught while it is still just a row in a sheet. The cost of fixing it there is near zero. The cost of fixing it after it reaches the ERP is an investigation.

The review is auditable. Every change has an owner, a timestamp, and a reason. Six weeks later, anyone can reconstruct why a price moved or a supplier was swapped. This turns reconciliation from detective work into a lookup.

The write is deterministic. Because the integration maps sheet rows to ERP calls in a predictable way, the same approved sheet produces the same ERP state every time. There is no room for a user to interpret a value differently mid-write.

Related changes stay together. A new supplier SKU is not three separate screens. It is one row (or one grouped set of rows) that the team reviews and approves as a unit. The combination is validated, not just the individual fields.

In practice, teams that move to this pattern report that the weekly catalog cycle stops being a source of incidents. It becomes a routine: extract, edit, review, approve, write, confirm. The ERP changes still happen — they just happen deliberately.

This approach is strongest for master data and reference data that changes in batches and where correctness matters more than speed.

• Supplier catalogs and vendor master data
• Product and SKU hierarchies
• Pricing tables and cost updates
• Customer or location reference data
• Tax codes, chart of accounts mappings, and other configuration data

It is less suited to high-volume transactional writes where latency matters and where each record is independent. If you are syncing millions of sales orders a day, a spreadsheet staging layer is the wrong tool. The pattern is designed for changes that are frequent enough to be a burden, but valuable enough to warrant review.

Staging in a spreadsheet is not free. It introduces a delay between proposal and commitment, and it adds a tool between the user and the ERP. Three tradeoffs matter.

Latency. Changes are not immediately live; they wait for the next review and write cycle. If a price change must be live within minutes, this pattern is too slow. If a daily or weekly cycle is acceptable, the delay is a feature — it is the review window.

Governance is manual by default. The spreadsheet only works if people actually review it. A staging sheet that nobody reads is just an extra place for data to rot. The discipline has to come from the team running the workflow, not from the tooling.

Double entry risk. If someone bypasses the staging sheet and edits the ERP directly, the sheet and the ERP drift apart. The pattern requires an enforcement decision: either block direct edits, or accept that the sheet is advisory rather than authoritative. Many teams enforce the boundary by making the integration the only path to ERP writes for the catalog domain.

Avoid this approach when a change is genuinely urgent and isolated. A single emergency price correction or a one-off supplier reactivation does not need a batch review cycle. The overhead would be disproportionate.

Avoid it when the ERP already provides a robust, configurable change-approval workflow. Many modern ERPs have native staging, approval, and audit capabilities. If the platform already gives you a review boundary, adding a spreadsheet layer is redundant complexity.

And avoid it for anything that is not master data. Transactional data — orders, shipments, invoices — has different latency and volume requirements. Staging those through a spreadsheet would create a bottleneck rather than a safety boundary.

If your team is making ERP changes directly and relying on memory to explain them later, the first move is not to build tooling. It is to map the current workflow.

Write down every type of write your team makes to the ERP catalog in a typical week: what data, which screens or imports, who does it, and what happens when it goes wrong. That map will show you where the review boundary is missing and which change types would benefit most from staging.