A retailer asked a deceptively simple question about managing six storage locations, farmers' markets and 15 team members:
How can each team member be attached to a location so that, when they make a sale, inventory is pulled from that specific location?
Source:
https://www.reddit.com/r/smallbusiness/comments/1fpechx/pos_and_inventory_systems_for_multiple_locations/
That question exposes the weakness in many multi-location demonstrations.
The software shows a list of branches. It can create staff accounts. It can display stock by location. Each feature works on its own.
But the retailer's real requirement is a relationship:
The right staff member uses the right selling device, the sale is attributed to the right operating location, and the quantity changes only in the stock record that supplied the item.
If any part of that relationship is wrong, the business can complete a valid payment and still damage its inventory record.
Before choosing or changing a POS, run a location assignment test with real products and realistic staff access.
One sale can carry several location identities
The phrase "sale at Location A" sounds precise. In practice, a transaction can involve several separate identities:
1. The physical place where the customer buys.
2. The location assigned to the POS device or register.
3. The staff member signed in to the device.
4. The location that owns the sellable stock.
5. The location used in sales and performance reporting.
6. The location or stock state that receives a return.
Those identities often align in a permanent shop. They may not align at a farmers' market, pop-up, mobile till, warehouse counter, shared register or cross-location return.
A team member might normally work at one branch but cover another for a day. A mobile device might travel with them. Products sold at a market might have been moved out of a warehouse in advance, or the retailer might expect sales to reduce a defined warehouse balance.
Neither approach is automatically correct. The dangerous approach is leaving the answer to assumption.
Start with two locations, not the whole business
Use the smallest test that can reveal a wrong relationship.
Create or select:
- Location A with 24 sellable units of one real SKU.
- Location B with 12 sellable units of the same SKU.
- Staff A, authorised for Location A.
- Staff B, authorised for Location B.
- A manager account that can approve controlled exceptions.
- One device or register with a clearly documented location.
Take screenshots or export the starting quantities. You need an agreed baseline so that nobody explains a mismatch away after the test.
Use a representative product rather than the easiest one. If the business sells variants, choose a size or flavour that staff could confuse. If barcode scanning is part of the workflow, use the real barcode. The purpose is to test the actual product, staff and location relationship.
Test 1: complete one ordinary sale
Sign in as Staff A at Location A and sell one unit.
After payment and completion, verify all of the following:
- Location A changes from 24 to 23.
- Location B remains at 12.
- The transaction records Staff A.
- The transaction records the intended selling location.
- The sales report attributes the sale according to the retailer's chosen reporting rule.
- The stock movement links back to the completed sale.
Do not accept "the total stock fell by one" as a pass.
If the combined total changed from 36 to 35 while the wrong branch supplied the reduction, the consolidated dashboard can look correct while both branches are wrong. One location is overstated and another is understated. That error appears later as a failed count, unnecessary transfer, stockout or unexplained adjustment.
Test 2: try the action that should not be allowed
Permissions become meaningful when the retailer tests a denied action.
While signed in as Staff A, try to view or change a Location B function that the role should not control. Depending on the job, that might be:
- changing Location B stock
- receiving a transfer for Location B
- applying a controlled discount
- opening another location's reports
- approving a return or adjustment
- changing a product record used by every branch
The correct result depends on the role design. The important result is that the restriction is deliberate and understandable.
Avoid solving every exception by making every employee an administrator. Broad access may make a demonstration easier, but it weakens accountability and makes accidental cross-location changes harder to explain.
Current Square documentation, for example, separates team location assignment, permission sets and personal passcodes used to attribute activity. Current Shopify documentation similarly separates POS roles, manager approval, location access and sales attribution.
Sources:
https://squareup.com/help/us/en/article/8356-add-and-manage-team-members
https://help.shopify.com/en/manual/your-account/users/roles/permissions/pos-permissions
The practical lesson is not that every provider uses the same model. It is that identity, location and permission are separate controls worth testing.
Test 3: return the item and decide where it belongs
A return exposes rules that a clean sale can hide.
Return the unit sold by Location A. Then answer:
- Can the return be accepted at another branch?
- Which location receives the quantity?
- Does it become sellable immediately?
- Can staff mark it damaged or awaiting inspection?
- Does the return preserve the original sale, staff and payment context?
- Who can override the default destination or stock state?
Adding one unit to the nearest branch is not always correct. A sealed product may return to sellable stock. A damaged or temperature-sensitive product may require inspection or disposal. A cross-location return may need to remain tied to the receiving branch while preserving the original sales record.
The test passes when the operational decision is explicit and the history explains it.
Test 4: transfer stock between locations
Now transfer five units from Location A to Location B.
A reliable transfer is not one invisible quantity subtraction followed by an addition. It is a controlled handoff with a sender, receiver and status.
Check that the workflow can show:
- the origin and destination
- the products and quantities requested
- who prepared or approved the movement
- what left the origin
- whether stock is in transit
- what the destination actually received
- any short, damaged, delayed or rejected quantity
- when each side confirmed the event
Test a partial receipt. Send five units and receive four. The missing unit should not disappear into a corrected total with no explanation.
Current Shopify transfer documentation distinguishes origin, destination, in-transit stock and received quantities. Its POS documentation also separates fulfilment at the origin from receipt at the destination.
Sources:
https://help.shopify.com/en/manual/products/inventory/inventory-transfers/creating-and-managing-transfers
https://help.shopify.com/en/manual/sell-in-person/shopify-pos/inventory-management/fulfilling-and-receiving-transfers
The same operating principle applies regardless of platform: both sides of a movement need evidence.
Markets and pop-ups need a stock rule, not just a name
Temporary selling locations create a difficult but common choice.
One retailer may create a separate market location and transfer stock into it before trading. Another may configure the mobile selling point to use stock owned by a permanent location. A third may use a smaller market allocation that returns to a warehouse after the event.
Choose the model that reflects how the business controls physical products. Then test:
- how products are assigned before the event
- which staff and devices can use the location
- how sales reduce the chosen stock
- what happens when two sellers use the same allocation
- how unsold products return
- how damaged, sampled or missing units are recorded
- what the team does when connectivity is unavailable
Do not infer offline capability from the words "mobile POS." EzyCarto does not currently advertise offline selling or offline payment. A retailer considering EzyCarto should plan for reliable connectivity during sales and payment, and every retailer should test the actual network and provider conditions at the intended venue.
Make manager approval narrow and visible
Some actions genuinely require an exception:
- a cross-location return
- a large discount
- a negative-stock sale
- an unplanned transfer
- a manual inventory adjustment
- temporary access to another branch
The answer is not to block every exception or allow every staff member to perform it freely.
Use a manager approval path that records the original user, approving user, location, action and reason. This preserves the difference between routine work and an authorised exception.
During the test, ask the frontline employee what they see when approval is required. Then ask the manager what evidence they receive. A technically present approval button is not useful if neither person understands the request.
Read the activity history as an investigator would
After completing the sale, denied action, return and transfer, review the history without relying on anyone's memory.
Can another manager determine:
- which staff member acted
- which device or register was used
- which location the system applied
- which product and quantity changed
- what event caused the change
- whether a manager approved it
- what happened at the other location
- when the action occurred
The history should answer an operational question, not merely prove that a database row changed.
This matters when a count is wrong at the end of the week. A useful record lets the retailer distinguish a sale, return, transfer, receiving difference and manual adjustment. Without that context, every discrepancy becomes guesswork.
Where EzyCarto fits
EzyCarto Smart Inventory currently provides location-based stock views, movement logs, roles, access restrictions by function or location and activity records.
Smart Inventory:
https://ezycarto.com/smart-inventory
EzyCarto Supply Chain supports transfer orders between locations, stock updates across affected locations, sending and receiving validation, movement records and controlled access.
Supply Chain:
https://ezycarto.com/supply-chain
EzyCarto POS connects authorised staff and store selection with product search, barcode-assisted cart building, location inventory visibility, receipts and sales context.
EzyCarto POS:
https://ezycarto.com/solutions/ezycarto-pos
These are the building blocks for a connected multi-location workflow. They do not remove the retailer's responsibility to configure locations, staff access, return rules and transfer procedures correctly.
If you are evaluating EzyCarto, bring two locations, two staff roles and one real product to the demonstration. Ask us to help you map the intended workflow, then run the test against the supported configuration.
Run this test before you migrate
A location dropdown is not evidence that a multi-location POS will protect inventory truth.
The evidence is a completed workflow:
1. One authorised staff member sells one known unit.
2. Only the supplying location changes.
3. A restricted cross-location action is denied or approved correctly.
4. A return enters the chosen location and stock state.
5. A transfer preserves the sending, in-transit and receiving evidence.
6. The activity history explains every change.
Run the same test in the shop, warehouse, market or pop-up conditions where the system will actually operate.
Related guides:
https://ezycarto.com/blog/when-the-online-store-and-the-till-need-the-same-stock-truth
https://ezycarto.com/blog/before-you-buy-a-pos-test-the-inventory-handoffs
The question is not only whether the software supports multiple locations.
It is whether your team can prove that every important stock movement belongs to the right place.