A Store-Code Reconciliation Workflow for Local Inventory Feeds

Why inventory errors often begin with identity mapping

A retailer may have accurate stock counts and prices but still associate the data with the wrong store. Local inventory workflows depend on stable identifiers: the store code must match the relevant Business Profile or store source, and the product identifier must align with the primary product data. A mismatch is a join failure, not simply a copy-editing error.

Google's Merchant Center guidance says the store_code value is case-sensitive and must match the store codes supplied for the relevant locations. Its local inventory instructions also identify required fields such as store code, product ID, quantity, price and availability. See store code specifications and local inventory data upload guidance.

Reconcile three tables before upload

Maintain three controlled tables rather than one giant spreadsheet:

1. Store master: internal branch ID, approved Merchant Center store code, public branch name, active status and effective dates.
2. Product master: stable product ID, variant identifiers and primary feed ID.
3. Inventory snapshot: store code, product ID, quantity/availability, price, currency and snapshot timestamp.

Use the internal branch ID as the join key in your own systems, but send the exact required store_code expected by the destination feed. Do not assume a branch display name is a safe identifier: two stores can share a name, and a name can change while the location remains the same.

Run these preflight tests

• Every active inventory row maps to exactly one active store-master row.
• Every product ID exists in the primary product source.
• Store codes match exactly, including case and leading zeros where applicable.
• The same internal store is not mapped to two live store codes without an approved migration plan.
• Price and availability have a timestamp and source owner.
• Closed or not-yet-operational branches are excluded according to the feed's current rules.

A useful exception output is row_id | failure_type | store_code | product_id | source_system | owner | next_action. Group exceptions by cause so one broken mapping can be corrected once instead of editing hundreds of rows individually.

Example: the invisible mismatch

Suppose the inventory system sends RJ-04, while the store source expects rj-04. A human reviewer may read these as the same code; a case-sensitive feed field may not. Fix the source mapping and add a regression test rather than manually changing every export.

Avoid overstating availability

A feed row is not proof that every customer can purchase the item immediately. Decide how often stock is refreshed, what quantity threshold triggers “unavailable,” and how online reservations or returns affect inventory. If the system cannot provide reliable store-level stock, do not manufacture precise availability claims.

Deliverable

Keep a dated reconciliation report with row counts, failed joins, corrections, approver and upload outcome. That gives merchandising, ecommerce and store operations a shared audit trail.

Sources and limitations

Merchant Center requirements and destinations can change. Confirm current eligibility and feed specifications for the retailer's account before enabling local inventory features.