Syncing Your Online Store Stock with Physical Shop Till: A Guide for African Retailers

The cost of overselling for African SMB retailers

When a customer buys the last unit of a product on your webshop while the same item has just been scanned at the physical till, you end up with a promise you cannot keep. In many African markets, that broken promise means a lost sale, a damaged reputation, and a cash‑flow hit because you must refund or source the product at a higher price. Overselling also skews your purchasing data — you think you have stock that does not exist, so you under‑order the next replenishment cycle. The result is a cascade of stock‑outs that can stall an entire product line for weeks.

For a small retailer operating on thin margins, every unit counts. Manual spreadsheets or periodic CSV uploads cannot keep pace with the speed of a busy shop floor and an online cart that runs 24/7. The fix is to make the online store and the till read from the same ledger in real time, so a sale in either channel instantly reduces the available quantity everywhere.

Choosing a stock‑sync method that works with low bandwidth

African retail environments often contend with intermittent internet, limited data bundles, and shared Wi‑Fi hotspots. A sync architecture that assumes constant high‑speed connectivity will stall, leaving gaps where overselling can creep back in. Two practical approaches fit low‑bandwidth realities:

• Edge‑first batch sync – The POS terminal stores every transaction locally in an encrypted queue. When a connection is available (even a brief 3G burst), the queue is pushed to the central ERP. The webshop polls the ERP on a configurable interval (e.g., every 5 minutes) and updates its displayed stock.
• Lightweight webhook with fallback – If the shop has a reliable broadband link at the counter, a simple HTTP POST from the POS to the ERP on each sale keeps the ledger current. The webshop subscribes to the same webhook endpoint; if the webhook fails, the POS falls back to the local queue described above.

Both methods avoid heavyweight middleware, require only a modest API endpoint, and can be implemented with the existing ERP’s REST or GraphQL interface. The key is to design the sync so that a temporary loss of connectivity never results in divergent stock numbers.

Mapping online SKUs to ERP item codes

Your webshop likely uses a SKU format like SHOP‑TSHIRT‑RED‑M while the ERP stores items as ITM‑00123. A reliable sync hinges on a one‑to‑one mapping table that lives in the ERP, not in the webshop. Follow these steps:

1. Export the ERP item master – Pull the list of active items with their internal codes, descriptions, barcodes, and variant attributes (size, colour, etc.).
2. Create a mapping spreadsheet – Add a column for the webshop SKU. Match each ERP item to its online counterpart. Flag any items that exist only in one system; they will need either a new ERP record or a webshop de‑listing.
3. Load the mapping into the ERP – Most modern ERPs allow a “SKU alias” table. Import the spreadsheet so the ERP can translate inbound webshop orders to the correct internal item code instantly.
4. Validate with a test order – Place a dummy order on the webshop for a mapped SKU. Confirm the ERP creates a sales order against the right item and that the available quantity drops in both systems.

Keep the mapping table under version control. When you launch a new product line, add the mapping before the first online listing goes live. This prevents “orphan” SKUs that the ERP cannot recognise.

Real‑time vs. batch sync – when each makes sense

Real‑time sync (webhook or push) gives the tightest inventory accuracy: the moment a cashier scans a barcode, the webshop’s available count drops. Use real‑time when:

• You sell high‑velocity, low‑stock items (e.g., phone accessories, fast‑moving FMCG).
• Your shop has a stable internet connection at the till.
• You run flash sales or limited‑edition drops where a few seconds of lag could cause oversell.

Batch sync (scheduled pull/push) is safer when:

• Connectivity is unreliable or metered.
• You manage a large catalogue with many slow‑moving SKUs; a 5‑minute lag is acceptable.
• You want to reduce API call volume to stay within ERP rate limits.

A hybrid model works well for most African SMBs: enable real‑time for the top 20 % of revenue‑generating SKUs (identified via ABC analysis) and batch the rest. The ERP can tag items with a “sync mode” flag, and the POS applies the appropriate logic automatically.

Testing the flow with a pilot product line

Before rolling out to the full catalogue, run a controlled pilot on a single product family — for example, a range of locally sourced cotton shirts. The pilot checklist:

1. Select 10‑15 SKUs covering different sizes and colours.
2. Enable the chosen sync mode (real‑time or batch) for those SKUs only.
3. Simultaneously sell – Process 5 in‑store sales and 5 online orders within a 30‑minute window.
4. Observe the ledger – Verify that the ERP shows a single consolidated quantity decrement for each SKU, and that both the POS screen and the webshop product page reflect the same remaining stock.
5. Inject a failure – Disconnect the POS from the internet for 10 minutes, complete a sale, then reconnect. Confirm the queued transaction posts and the webshop updates once the batch runs.
6. Document exceptions – Note any mismatches, latency spikes, or error logs. Adjust the sync interval or queue retry policy accordingly.

Once the pilot passes without oversell incidents for a full business day, expand the sync to the next product category. Incremental rollout limits risk and lets the team build confidence in the new workflow.

Ongoing monitoring and exception handling

A live sync is not a set‑and‑forget system. Build a lightweight monitoring dashboard inside the ERP that surfaces:

• Sync lag – Time between a POS sale and the webshop quantity update. Alert if lag exceeds your SLA (e.g., 2 minutes for real‑time SKUs).
• Queue depth – Number of pending transactions on the POS. A growing queue signals connectivity issues.
• Mismatch count – Instances where the ERP’s available qty differs from the webshop’s displayed qty by more than a configurable threshold.

Define an exception‑handling runbook:

1. Automatic retry – The POS retries failed pushes every 30 seconds up to 5 attempts.
2. Manual reconciliation – If a mismatch persists after 15 minutes, the store manager runs a “stock take” for the affected SKUs and posts a correction journal in the ERP.
3. Escalation – Persistent queue buildup (>100 pending transactions) triggers an SMS to the IT focal point and the ERP admin.

Schedule a weekly review of the dashboard with the store lead and the finance clerk. Use the data to fine‑tune sync intervals, adjust which SKUs run real‑time, and plan bandwidth upgrades where needed.

Bringing it all together

By anchoring both your online cart and your physical till to a single ERP ledger, you eliminate the manual uploads that cause overselling, reduce the time staff spend reconciling spreadsheets, and gain a true picture of stock across every warehouse and shop floor. The steps above — choosing a bandwidth‑aware sync method, mapping SKUs once in the ERP, piloting on a focused line, and monitoring continuously — give you a practical roadmap that works even when internet is spotty.

When you’re ready to tighten stock control across your stores and warehouses, see how StockPRO can help.