The problem
A shared inventory spreadsheet usually starts well. One tab lists SKU, description, location, quantity on hand, reorder point and supplier. One person updates it after each receipt or issue. The trouble starts when a second person edits the same file. Two saves collide, and the last one wins. A row may show fourteen units when the shelf holds nine, and nobody can explain the gap.
The sheet stores current state, not history. People overwrite the quantity cell instead of recording a receipt, issue, transfer or adjustment. You cannot answer who changed the count, when they changed it, or why. Hidden columns and extra tabs creep in. Copies get emailed to finance and the warehouse. Soon two versions disagree and both look official.
Permissions are weak. Anyone who opens the file can edit cost, delete rows or break a formula. Data validation is easy to bypass. Duplicate SKUs appear. Units get mixed, so a case and an each land in the same column. Reorder points sit unused. Phone use is clumsy, and barcode scanners rarely fit the sheet. Inventory counts become a debate rather than a check. The fix is a small internal web app with a clear data model and real controls.
What a good solution looks like
A good app has an item master and a movement ledger. Each item gets a unique SKU, description, unit of measure, supplier, reorder point and one or more locations. You do not type over on hand. You record a stock movement: receipt, issue, transfer, adjustment or count. On hand is calculated from those movements. This single rule gives you history, audit and a way to correct mistakes without erasing the past.
Roles should match the work. Warehouse staff can receive and issue. A supervisor can approve adjustments. Finance gets read access to quantities and costs. An admin manages items and locations. Sign in through your identity provider so each action ties to a person, not a shared password. The audit trail should be append only. Every movement needs a user, timestamp, reason code and reference, such as a purchase order or sales order number.
The screens should be fast on a phone or tablet. Search by SKU or name. Scan a barcode if you need it. Show the current location and quantity before someone submits a movement. Add a low stock report, an item history view and a cycle count sheet. Import the current spreadsheet and export CSV for finance or your BI tool. Keep scope tight. This is an inventory tool, not a full ERP.
How to build it
Start with one workflow. Pick receiving and issuing at one site, or cycle counts in one stockroom. Write the rules before you build. Is negative stock allowed? Do transfers need approval? Which roles can adjust? What unit conversions are allowed? Clean the spreadsheet in parallel. Keep one row per SKU per location, fix duplicate SKUs, fill missing units of measure and remove merged cells and hidden rows. Save a copy before you change anything.
Model the data in a relational database. Use tables for items, locations, stock movements, users and roles. Add constraints: unique SKU, numeric quantities, valid movement types, required reason codes. Store an opening balance as a movement, not as an editable field. Build the item list, item detail, movement history, receive form, issue form, transfer form, adjustment form and count form. Add validation and a confirmation step. Build a CSV import with a dry run and an error report.
Connect sign in to your identity provider and map roles. Set up a staging copy and import the cleaned file there. Reconcile opening balances by SKU and location against the spreadsheet. Fix every mismatch before go live. Pilot with two or three users for one or two weeks. Freeze the old sheet to read-only at cutover so there is one source of truth. Train the team on the five actions they will use daily. Leave a short runbook.
Risks and how to manage them
Data quality is the first risk. Duplicate SKUs, mixed units and missing locations will poison the app if you import them. Run a cleaning pass, enforce constraints and show an import error report. Reconcile the opening balances line by line. Do not import old notes and hidden tabs just because they exist. If a field is not needed for a movement, leave it out of version one.
Adoption is the second risk. People fall back to the spreadsheet when the app is slower or unclear. Make the common actions obvious. Put search first. Use large buttons and scanner support where it helps. Name one owner for the inventory data. Remove edit access to the old sheet at cutover. Watch for shadow copies and ask the warehouse team what still feels hard.
Scope and control are the third risk. Teams often add purchasing, accounting and forecasting before the basic ledger works. Resist that. Add reason codes for adjustments and negative stock exceptions. Hide cost fields from roles that do not need them. Back up the database and test a restore. Review the audit log for gaps. If your stockroom has no network, use paper count sheets and enter them at a desk the same day.
How to measure success
Define success measures before launch. Track the time to record a receipt, the time to answer where a SKU sits, the number of duplicate SKU errors, the number of negative stock exceptions and the number of movements without a reason code. Use counts and trends, not one big report. Check cycle count variance by location. Watch whether the low stock report is opened and acted on.
Review those measures weekly after cutover. Sample a few movements and match them to physical stock. Confirm every movement has a user, time and reason. Confirm the finance export runs and the totals match the ledger. Ask users how many clicks it takes to receive a pallet. Keep a short list of fixes and ship them in small batches. Retire the spreadsheet only when the app answers the daily questions without a side file.
If you lack build capacity, compare options. An in house build gives control but needs design, database and support time. A larger platform may add modules you do not need. The Internal tool sprint from Cloudverg is a fixed price of $16,500 and runs four weeks for one workflow end to end, with sign-in, roles, change history, data import, exports, training and a runbook. Treat it as one option and check the fit against your scope.
Frequently asked questions
Can I just use a spreadsheet with better controls?
You can add validation, protected ranges and a change log, but shared spreadsheets still struggle with concurrent edits, row level permissions and reliable movement history. Use that as a bridge, not the final system. Move to an app when more than one person changes inventory.
What data should I import first?
Start with item master, locations, current on hand, reorder points and supplier names. Leave old notes and hidden tabs out until you decide they matter. Reconcile opening balances as movement records before cutover.
Do I need barcode scanners?
Not for the first version. Search and simple forms can work. Add barcode scanning when receiving or picking volume makes typing the bottleneck. Test devices on the floor before buying hardware.