When a stock spreadsheet starts costing more than it saves

A stock spreadsheet is a genuinely good decision for a long time. It costs nothing, everyone can read it, and it does not need a project. Businesses that replace it too early spend money on software to solve a problem they did not have yet.

The difficulty is that it does not fail in a way you notice. There is no outage. It carries on producing numbers, and the numbers get gradually less true, and the cost of that shows up somewhere that is not labelled inventory: a customer told an item was in stock when it was not, a purchase order for something already in the storeroom, an afternoon spent counting shelves before a supplier meeting.

The five signals it has crossed over

• Somebody reconciles it by hand. If a person regularly walks the shelves to find out what the sheet got wrong, you are paying a salary to be a database.
• Two people need it at once. The moment a copy gets emailed, there are two truths, and the merge is manual.
• The stock number and the sales channel disagree. Especially with an online store, where the disagreement is visible to customers before it is visible to you.
• Nobody can answer what it was on a past date. Spreadsheets overwrite. History is what you need when a discrepancy has to be explained.
• One person understands the formulas. This is a business continuity problem, not a tooling preference.

One of these is normal. Three at once means the spreadsheet is now the expensive option, and the expense is being paid in labour and in errors rather than in a licence fee, which is why it does not appear in any budget.

The part that is not optional in Egypt

There is a local requirement that changes this decision, and it catches people out because it sits in tax rather than in operations. Invoicing in Egypt is no longer a document you produce, it is a document you register.

The Egyptian Tax Authority describes its eInvoicing and eReceipt platform as the solution "used by taxpayers to register their issued documents with the Tax Authority" and to be notified of events on those documents. The integration requirements are specific rather than nominal. The getting started documentation sets out that a taxpayer must register a digital profile, register each ERP or POS system, obtain an eSeal X.509 certificate configured in the system submitting documents, and call the identity service for a session token before using the APIs, which are REST and JSON over TLS.

The practical consequence for a small business is that stock, sales and invoicing stop being three separate concerns. If the invoice has to be submitted and validated programmatically, then whatever holds your stock has to be connected to whatever issues your invoices, and a spreadsheet is not going to be either of those things. This is the single most common reason we see a stock sheet finally get replaced, and it tends to arrive as a deadline rather than a choice.

What the first version has to do, and what it does not

The most common failure is building the system a large distributor needs. The first version should do less than anyone suggests in the requirements meeting.

• One record per item, one place. With a code that matches whatever the supplier and the sales channel already use.
• Movements, not balances. Store every in and out as an event. The current level is calculated. This is what gives you history, and retrofitting it later is painful.
• Multi-user by default. Even for two people.
• An adjustment that requires a reason. Stock counts will differ from the system. The value is in knowing why and how often.
• A connection to the sales channel. One direction is enough at first: sales reduce stock automatically.

What can wait: forecasting, barcode scanning, multi-warehouse, supplier portals, automated reordering. Every one of those is reasonable eventually and none of them helps if the base record is wrong.

Buy before you build

We build software, and this is still the right advice for most cases. Standard inventory products handle standard inventory well, and stock control is a solved problem in the general case.

Building is worth considering when the process is genuinely unusual, when the integration matters more than the features, which is common where an off-the-shelf product does not speak to the local invoicing platform, or when the licence cost per user starts to exceed what a small internal tool would cost to maintain. The honest test is whether you are building because your business is different or because configuring the product is boring. It is usually the second, and it is a costly reason.

The honest limit

If you have under about a hundred items, one person touching stock, and no online sales channel, a spreadsheet is very likely still the correct answer, and any consultant telling you otherwise is selling something. The cost of a system is not the build, it is that somebody now has to keep it running, and below a certain volume that is a worse trade.

The other honest point is that a system does not fix a process. If stock goes out of the door without being recorded, software records that fact more precisely and changes nothing. The discipline has to exist first, and a business that cannot maintain a spreadsheet accurately will not maintain a database accurately either.

How to decide this month

Count how many hours a week go into reconciling, and price them. Count how many times in the last quarter you told a customer something about availability that turned out to be wrong. Check what your invoicing obligations actually require and when. If those three numbers are small, keep the spreadsheet and revisit in six months.

If they are not, scope the smallest thing that removes the reconciliation, and resist everything else, which is the discipline in scoping a project before anyone writes code. The same pattern of a business quietly running on spreadsheets past their useful life is one we have written about in another sector in the three tools every training centre rebuilds in spreadsheets, and the reporting half of it usually turns out to be separable, which is the case in automating manual reporting without buying a BI platform.

If you are setting up the sales side at the same time, the operational groundwork for selling online in the local market is covered in Arabic by KF Agency in a step by step guide to opening an online store in Egypt. It is written in Arabic and is aimed at the commercial setup rather than the systems, which is the half this note deliberately does not cover.