The Cross-System Price Discrepancy Playbook

This playbook enables you to diagnose and resolve a price discrepancy that appears when product pricing is correct in one system but incorrect downstream. The target end state is a verified understanding of which hop in the storefront → ERP → POS → shelf-label chain introduced the wrong value, who last wrote it, and a plan to correct it with the least invasive change that will hold.

The business reason this matters: a wrong price in any downstream system produces either lost margin (price too low) or lost sales and customer friction (price too high). When on-call spends hours tracing a price across three or four systems without a structured method, the discrepancy persists and the root cause is never confirmed.

Systems affected:

Decisions

Confirm the following with the business owner before starting:

The tools involved are the four systems in the chain and the interfaces you use to query them.

• Storefront: The e-commerce system. You query its product price endpoint or database to establish the current displayed price.
• ERP: The product master. This is where price changes typically originate. You query its product record and audit history.
• POS: The physical-store point-of-sale system. You query its price table or API to see what price is charged at checkout.
• Shelf-label system: The label-generation system. You query its data source to see what price is printed on in-store labels.
• Audit log or change-history source: Each system that retains price history exposes it via API, database table, or admin UI. The specific mechanism will vary by vendor; the capability you need is the ability to see who changed what and when for the price field.

The implementation does not depend on a specific vendor. If a system lacks a native audit log, you may need to check the integration layer (the sync job or middleware) for its own logs of what values it pushed and when.

What this step does

You capture a point-in-time snapshot of the price in all four systems for the same product. This confirms the discrepancy exists, identifies which systems disagree, and gives you a baseline to compare against after any fix.

Actions

1. Choose the product identifiers for the discrepant product(s). Record them in a working file:

cat > product_ids.txt <<'EOF'
SKU: <SKU>
UPC: <UPC>
InternalID: <PRODUCT_ID>
EOF

1. Query the storefront price for the product. The mechanism depends on the system; a typical API call looks like:

curl -s "<STOREFRONT_API>/products/<SKU>" \
  -H "Authorization: Bearer <READ_ONLY_TOKEN>" | jq '.price'

1. Query the ERP product record and its price field:

curl -s "<ERP_API>/products/<SKU>" \
  -H "Authorization: Bearer <READ_ONLY_TOKEN>" | jq '{price, currency, updated_at}'

1. Query the POS price for the same product:

curl -s "<POS_API>/products/<SKU>" \
  -H "Authorization: Bearer <READ_ONLY_TOKEN>" | jq '{price, updated_at}'

1. Query the shelf-label data source. This may be a database or an API:

curl -s "<LABEL_API>/products/<SKU>" \
  -H "Authorization: Bearer <READ_ONLY_TOKEN>" | jq '{price, updated_at}'

1. Record all four values in a comparison table. Include currency and timestamp for each.

Important considerations

• Do not modify any system in this step. Read-only queries only.
• If a system returns multiple price fields (list price vs. sale price), record which field you queried and be consistent across systems. A mismatch between "list price" and "sale price" is a common source of false discrepancies.
• If a system is unreachable, record it as unknown rather than assuming it matches.

What this step does

For each system holding a wrong price, you determine who last wrote the value and when. This tells you whether the wrong value arrived via an automated sync or a manual change, which determines the fix approach.

Actions

1. For each system with an incorrect price, query its audit log or change-history for the product's price field.

A representative audit-log query might look like:

curl -s "<SYSTEM_AUDIT_API>/products/<SKU>/history" \
  -H "Authorization: Bearer <READ_ONLY_TOKEN>" | jq '.changes[] | select(.field == "price")'

1. For each price change event, record:

• the old value
• the new value
• the timestamp
• the actor (user ID, service account, or system name)

1. Identify the last event that set the current incorrect value. That event's actor is the last writer.

1. Determine whether the last writer was:

• an automated sync job (identifiable by a service account name, a system-to-system API call, or a batch job identifier)
• a manual admin change (identifiable by a human user ID)
• an import or bulk operation (identifiable by a file name or import session ID)

1. If a system has no audit history for the price field, check the integration layer's logs. Look for records of what value the sync pushed and when. If neither source exists, record that the last writer for that system cannot be determined — this is a finding, not a failure.

Important considerations

• The last writer is not automatically the root cause. A manual correction in one system that then gets overwritten by the next sync points to the sync, not the manual change. Records both the write and the subsequent history.
• If the incorrect value was written by a sync job, check whether the sync pulled the value from the source of truth or from another intermediate system. A sync that sources from a non-authoritative system is a common root cause.

What this step does

You reconstruct the direction of data flow between systems — who syncs to whom — and identify the exact hop where the correct price became the incorrect one.

Actions

1. Document the sync topology. Confirm the direction of each connection. A typical topology is:

ERP ──► Storefront
ERP ──► POS
POS ──► Shelf-label

Confirm this against your actual environment. Some deployments sync directly ERP → shelf-label; some sync POS → storefront. The topology you document must match what is actually deployed.

1. For each sync hop, determine what value it last transmitted for this product. Use the integration layer's logs, the destination system's change history (which shows the inbound write), or the source system's outbound feed.

1. Walk the chain in order from source of truth to final destination. At each hop, ask:

• Did the value leaving this hop match the value entering it?
• If not, this hop introduced the discrepancy.

1. If the incorrect value exists in a system fed by another system that holds the correct value, the hop between them is suspect. If the incorrect value exists in a system that is a source for others, the problem may propagate downstream.

Important considerations

• The wrong hop is not always the last writer. If the ERP is correct, POS is wrong, and shelf labels are wrong, either the ERP→POS sync introduced the error, or POS was independently edited incorrectly and shelf labels inherited it. The last-writer data from Step 2 distinguishes these.
• Some syncs transform values (for example, currency conversion or rounding rules). If the incorrect value differs from the correct value by a consistent factor or rounding pattern, check the sync's transformation logic rather than assuming a data error.

What this step does

You choose a fix action scaled to the nature of the discrepancy — a one-off correction versus a systemic sync failure — and apply it. The principle is least-to-most invasive: correct the data first, then address the process only if the evidence warrants it.

Actions

1. Classify the discrepancy into one of three categories:

• One-off data error: A single product has a wrong price due to a manual mistake or a one-time event. The sync itself works correctly for other products.
• Recurring sync failure: The same product or a pattern of products gets the wrong price every sync. The sync logic, mapping, or transformation is faulty.
• Propagation-only: The wrong value exists only because it was pushed from an upstream system. Fixing the upstream system corrects the downstream.

1. Apply the appropriate fix:

For a one-off data error:

• Correct the price in the source of truth (usually ERP).
• Confirm the correction propagates to downstream systems on the next scheduled sync.
• If propagation is not automatic, trigger a manual sync for this product only, then re-verify all four systems.

For a recurring sync failure:

• Do not correct the value in the destination only — it will be overwritten on the next sync and you will be back on call.
• Identify the root cause in the sync logic. Common causes: the sync reads the wrong field, applies an unwanted transformation, or maps the wrong product identifier.
• Correct the sync configuration or code in a staging environment first if the change is non-trivial. If the change is a simple mapping correction, apply it directly after review.
• After the fix, run a fresh sync and re-verify.

For propagation-only:

• Correct the value at the source system (the system feeding the wrong value).
• The downstream systems will correct themselves on the next sync. Verify after the sync completes.

1. After applying the fix, re-run the comparison from Step 1 for the affected product(s).

Important considerations

• Never correct a price directly in a destination system that is fed by a sync, unless you are certain the sync will not overwrite it. Otherwise you are applying a temporary fix that will disappear.
• Currency and rounding: if the discrepancy is a consistent factor, verify the sync's currency conversion and rounding settings before changing any data.
• If the fix involves changing sync code or configuration, treat the change as a production change: review, test in staging, and schedule the deployment.

What this step does

You confirm the fix holds beyond the immediate product, and you determine whether the same root cause could corrupt other products. If it can, you document the issue and assign ownership.

Actions

1. Re-query all four systems for the originally affected product. Confirm all four prices now match the source of truth.

1. If the discrepancy was a recurring sync failure, assess blast radius. Run a comparison across a sample of products that pass through the same sync path:

# Example: compare ERP price vs POS price for 100 sampled products
# The exact query depends on your systems; the point is to check for other discrepancies

1. If other discrepancies exist, record them as a separate finding and estimate the scope. Do not attempt to correct them all in this session unless the business owner directs otherwise.

1. If the root cause was systemic (sync logic, transformation, or mapping), write a short incident note that includes:

• the product(s) affected
• the wrong hop
• the last writer
• the root cause
• the fix applied
• whether other products are at risk

1. Assign an owner for the systemic fix and a follow-up date. If the pattern suggests a broader data-quality issue, escalate to the team that owns the sync infrastructure.

Important considerations

• A fixed single product does not mean the problem is solved. If the sync logic was wrong, the same failure will recur on other products. The verification in this step is what distinguishes a fix from a patch.
• If you corrected a one-off error, no systemic follow-up is needed. Do not invent a broader issue where the evidence does not support one.

The validation below tests the complete chain as a system, not just the originally affected product.

Rollback

If the fix causes new problems — for example, a sync change corrupts prices for other products — the return path depends on what you changed.

• If you corrected a product's price in the source of truth: the prior value may be recoverable from that system's audit log. Restore the prior value from the change history. There is no code to roll back.
• If you changed sync code or configuration: revert the change through the same deployment process used to apply it. If the change was applied directly to production, restore the previous configuration file or code revision from version control, then redeploy.
• If you triggered a manual sync: there is no rollback for a sync itself. The corrective action is to re-sync with corrected source data, which is what you did in the fix. If the sync worsened other data, restore those values from their respective audit logs.

Do not attempt to roll back by manually editing every downstream system. That reintroduces the drift you are eliminating.

Edge cases

• System without audit history. If a system does not retain price change history, the last writer cannot be determined. State this as a limitation and base the diagnosis on the other three systems. Recommend, as a follow-on, enabling change capture for the price field.
• Multiple price fields. A system with list price, sale price, and effective dates can appear to disagree when you compare the wrong field. Confirm you are comparing the same semantic field in every system.
• Currency conversion. If downstream systems display in a different currency, a wrong conversion or stale exchange rate can produce a consistent-factor discrepancy. Check the conversion logic before assuming a data error.
• Time-zone differences in timestamps. Audit logs may use different time zones. Normalize all timestamps to UTC before reconstructing the write sequence.
• Retired or archived products. A product may exist in some systems but not others, causing a query to fail. Record which systems lack the product and exclude it from the comparison.
• Rate-limited APIs. If a system's API is rate limited, batch your queries and add delays. Do not parallelize aggressively against a rate-limited endpoint.
• Sync partially writes. Some syncs write a subset of fields. If a sync updated the product name but failed on price, the price field may be stale rather than actively wrong. The audit log timestamp distinguishes stale from actively overwritten.

After the immediate fix holds, do one of the following, depending on what the diagnosis revealed:

• If the discrepancy was systemic: schedule the code or configuration fix through the normal release process, and add a monitoring check that compares price fields across systems on a periodic basis so the next occurrence is caught automatically rather than by a customer or store associate.
• If the discrepancy was one-off: document the incident in your operations log with the identifying pattern (product ID, wrong hop, last writer, and fix), so a future on-call can recognize the pattern and skip the full diagnosis.
• Enable audit history on any system in the chain that lacks price change capture. Without it, the next incident cannot be fully diagnosed.
• If the chain itself is fragile — for example, a POS system that cannot log who changed a price, or a sync that silently overwrites manual corrections — review the architecture to determine whether the sync direction or the authoritative-source assignment should change.

If the diagnosis points to a recurring, multi-product failure pattern that a config fix cannot contain, that is the point to review the sync architecture with Octacer — the goal is to stop the recurrence rather than keep correcting individual prices.