The Second Shop Is Where Spreadsheet Inventory Starts to Lie

A spreadsheet can be perfectly adequate for one shop.

One owner may receive deliveries, update quantities, sell products and investigate differences. When a number looks wrong, the explanation is often still in that person's memory.

Then the second location opens.

Stock leaves one branch and has not yet arrived at the other. Two people update the same product at different times. A return is accepted in a different shop from the original sale. A delivery is physically unpacked before anyone records it. The total quantity may still look plausible while the location-level picture is wrong.

The spreadsheet has not suddenly become dishonest. It has lost the human context that once made its numbers trustworthy.

A current apparel and accessories retailer described the transition plainly: things started to fall apart when I opened the 2nd location.

Store-to-store transfers no longer reconciled. Real-time availability became difficult to see. Over-ordering and stockouts began happening around the same operation. Yet changing systems felt risky because the spreadsheet had worked before and staff already knew the routine.

Source discussion: https://www.reddit.com/r/Entrepreneurship/comments/1w07i9h/when_did_inventory_management_software_for_retail/

That is the useful decision point. Do not replace a spreadsheet because it looks basic. Replace it when routine retail decisions depend on stock figures the team can no longer reconcile, explain or update reliably.

The second store adds states, not just rows

At one location, moving a box from the stockroom to the shop floor may not change the branch total. At two locations, moving that box changes several operational facts:

• which branch can promise the product to a customer
• whether the item is still available to sell at the sending store
• whether the receiving store has accepted the quantity
• whether the stock is currently in transit
• who owns a shortage or damage investigation
• which location should reorder next

A spreadsheet can contain columns for all these facts. The harder question is whether the team records each event at the moment it happens and whether the history remains traceable afterwards.

Current Lightspeed documentation treats an inter-location transfer as a workflow between a sending location and a receiving location. Receipt at the destination is a distinct event. That distinction matters because stock leaving one store is not automatically stock available in another.

Reference: https://retail-support.lightspeedhq.com/hc/en-us/articles/228840567-Transferring-items-between-locations

If a transfer is represented as one person subtracting five units in Shop A and another person eventually adding five in Shop B, there is no dependable state between those edits. The business cannot tell whether the goods are moving, delayed, short, damaged or simply forgotten.

Six signs the spreadsheet is no longer a safe stock record

1. Transfers are typed but not received

The sending branch updates its quantity, but the destination has no formal receipt step. Differences are discovered only during a count or after a customer asks for an item that should be there.

2. Each location has a different version of availability

Staff keep local copies, message each other or add notes outside the main sheet. The central total no longer reflects what either branch can actually sell.

3. Adjustments have numbers but no reasons

A quantity changes from 12 to 9, but nobody can tell whether three units were sold, damaged, transferred, returned to a supplier or entered incorrectly.

4. Receiving depends on one person's memory

Deliveries are unpacked during a busy period and recorded later. If the responsible person is absent, purchase orders, physical stock and the spreadsheet drift apart.

5. Purchasing begins with a manual investigation

Before placing an order, someone phones both stores, walks the shelves or compares several files. The spreadsheet has become a starting hypothesis rather than a dependable buying record.

6. Staff work around the record to keep serving customers

Products are reserved in messages. Transfers are agreed verbally. Returns wait for a manager. The team is not being careless; it is compensating for a record that cannot represent the real workflow quickly enough.

One of these problems on its own may be fixable with clearer spreadsheet controls. When several are normal, the operating cost is no longer just administration. It includes missed sales, unnecessary purchases, customer disappointment and management time spent reconstructing events.

Decide whether to repair the spreadsheet or migrate

Before buying software, run a one-week inventory control test.

Choose 20 representative products:

• fast sellers
• variants such as size or colour
• one expensive product
• one product frequently transferred
• one item with regular returns
• one item bought from more than one supplier

For each product, ask:

1. Can either branch see its available quantity without calling the other?
2. Can the team explain every movement during the week?
3. Does a transfer remain visible from dispatch to receipt?
4. Can staff identify who made an adjustment and why?
5. Can purchasing use the record without repeating a physical count?
6. Does the closing system quantity match the physical count at both locations?

If the process passes, improve the spreadsheet rather than changing tools merely for appearance.

If it fails, classify the cause. A missing field can be repaired. A training issue needs a clearer operating rule. Repeated timing, ownership and traceability failures indicate that the business may need a transactional inventory system rather than a shared document.

Migration starts with product identity, not quantities

The most visible migration task is importing stock quantities. It should not be the first one.

First, decide what each product is.

Clean and standardise:

• product name
• SKU
• barcode
• variant, such as size and colour
• unit of measure
• cost and selling price
• tax treatment
• supplier reference
• active, seasonal or discontinued status

If the same jacket appears as Jacket Navy M, Navy Jacket Medium and a barcode-only row, importing the sheet may create three products instead of one trustworthy record.

This is why barcode inventory begins with the product record, not the scanner. A scanner can retrieve an identity quickly. It cannot decide which duplicate identity is correct.

Related guide: https://ezycarto.com/blog/barcode-inventory-starts-with-the-product-record-not-the-scanner

Do not clean everything forever before moving. Define a controlled set of active products, resolve the material duplicates and create a separate exception list for records that need later review.

Give every location and stock event an owner

Create the two store locations and any genuine warehouse or stockroom locations. Avoid inventing locations merely to describe a shelf or staff member if the distinction will not support a real decision.

Then assign responsibility:

• who receives supplier deliveries
• who can create a transfer
• who confirms dispatch
• who confirms destination receipt
• who can adjust stock
• who approves unusual or high-value adjustments
• who investigates count differences

Permissions should reflect these decisions. They should not be used as a substitute for them.

The existing EzyCarto multi-location test explains how to verify that staff, devices, sales, returns and transfers post against the correct branch once a platform is being evaluated.

Related test: https://ezycarto.com/blog/multi-location-pos-location-assignment-test

Establish opening stock without creating a moving target

Choose a cutover method and document it before counting.

A practical small-retailer sequence is:

1. Stop non-essential product edits for a defined period.
2. Export and preserve the original spreadsheet.
3. Import the cleaned active product catalogue without assuming quantities are correct.
4. Count representative high-risk products at both stores.
5. Enter opening balances with a date, location and accountable person.
6. Record every sale, return, receipt and transfer after that point in the trial system.
7. Keep a separate exception list rather than silently correcting unexplained differences.

The preserved spreadsheet is a rollback and audit reference. It should not remain an indefinitely editable second system of record.

Test the events that normally break the record

A successful login and a complete product list do not prove migration readiness.

Run real operational tests:

Receive a delivery

Confirm that the correct products and quantities arrive in the correct location. Test a partial delivery and one discrepancy rather than only a perfect order.

Sell and return an item in each branch

Check that the sale reduces the right location and that the return follows the intended stock state and branch rules.

Transfer stock between stores

Create, send and receive the transfer. Test a short receipt. The history should show what was expected, what left, what arrived and who handled each step.

Make a controlled adjustment

Record damage or a count correction with a reason. Verify that the original value and the responsible user remain visible.

Count the same products again

Compare the closing physical count with the system. Investigate every difference before expanding the trial.

These tests expose operating gaps while the scope is still small enough to fix.

Use parallel checking without creating parallel truth

A short parallel period can reduce migration risk. A permanent parallel system usually increases it.

Define the purpose of the check:

• validate opening balances
• confirm that location events post correctly
• observe staff adoption
• identify missing product fields
• test reports used for purchasing and customer promises

Set a beginning, an end and a decision owner. During the trial, one system must be designated as the transaction record. The other is a comparison reference, not an alternative place to enter whatever was missed.

At the end, review:

• unexplained quantity differences
• transfers still in transit
• delayed receiving
• duplicate products
• unrecorded workarounds
• staff questions and permission problems

Do not expand to every product until the representative workflow is stable.

What to evaluate in multi-location inventory software

Avoid turning the shortlist into a feature-count competition. Follow the events that created the need to migrate.

Ask each provider to demonstrate:

• one product identity with separate location quantities
• a transfer from request through dispatch and receipt
• stock visibly in transit
• partial or disputed receipt handling
• sales and returns posting to the correct branch
• role and location permissions
• adjustment reasons and activity history
• product import and duplicate handling
• exports and data ownership
• the purchasing report your team actually uses

If the provider cannot demonstrate the messy case, the polished dashboard is not enough.

Also ask what the system does not support. A clear limitation discovered in a demonstration is cheaper than an assumed capability discovered after cutover.

Where EzyCarto fits

EzyCarto is designed as a connected retail operations platform rather than a disconnected inventory add-on.

Its current Smart Inventory scope includes location-based stock views, quantities and movement logs, structured product imports, barcode and SKU workflows, role and location access, activity records and connections with checkout, supply-chain, CRM, loyalty and analytics functions.

Product overview: https://ezycarto.com/smart-inventory

That connected foundation can support a two-location stock record, but it does not remove the retailer's responsibility for clean product identities, opening balances, staff ownership and exception handling.

The right next step is not a full migration promise. It is a controlled demonstration using the events your current spreadsheet struggles to represent.

Bring five real products and ask to run:

1. an opening balance in both locations
2. a supplier receipt
3. a sale and return
4. a store-to-store transfer
5. a count difference and investigation

If the complete history remains clear to the people who will use it, expand the pilot. If it does not, document the gap before moving more data.

The decision is about trust, not sophistication

A spreadsheet is not a failure. It may be exactly the right tool for a small, controlled operation.

Growth changes the test.

When the second location makes stock movements harder to trace, availability harder to promise and purchasing harder to trust, the business needs more than additional columns. It needs a shared operating record with clear events and ownership.

Migrate because the current process can no longer answer ordinary questions reliably, not because software looks more modern.

Then migrate in stages, prove the messy workflows and keep the retailer's judgment in control.