The setup people describe is almost always the same. Stock lives in a storeroom, a workshop, or the back of a van. Somebody takes six boxes out, and the record of that is a scribble on a clipboard that gets typed up on Friday, or does not. A form on a phone looks like the obvious fix, because the person holding the box has a phone in the other hand and typing three fields takes fifteen seconds.
That instinct is correct, and it works better than most spreadsheet based attempts. The reason it works is worth understanding precisely, because the same reasoning shows exactly where the arrangement stops being enough.
What a form is actually good at here
A form is an instrument for capturing events. Somebody did something at a moment in time, and the form writes down what and when. Every submission appends a new row and nothing already recorded changes.
Inventory has two completely different data shapes inside it, and only one of them is an event.
Movements are events. Six units of part 4471 left the store at 09:14 on Tuesday, taken by the afternoon shift, for job 2208. That is a fact about a moment, it never becomes untrue, and it is exactly what an append only log is built to hold.
Stock levels are state. Part 4471 currently has nineteen units on the shelf. That number changes every time a movement happens, it is only ever true for an instant, and it is the answer to a question rather than a record of an event.
The whole design follows from keeping those two apart. The form captures movements. The stock level is calculated from the movements, not stored and edited. A team that tries to make the form update a running total is fighting the tool; a team that treats the form as a movement ledger gets something genuinely reliable, because there is no shared cell for two people to overwrite at the same time.
That distinction is also what makes a form better than letting everybody type directly into a shared sheet. Two people editing the same stock cell from two phones produce one silent loss. Two people submitting movements produce two rows, both correct, in the order they arrived.
The movement ledger, laid out
A working movement form carries five things and resists carrying more.
The item, as a dropdown rather than typed text. This is the single most important choice on the form. A typed item name arrives as "part 4471", "4471", "Part-4471", and "4471 bracket", and every one of those is a different item to a spreadsheet formula. A dropdown means the value is always exactly one of the strings the formulas expect. The cost is maintenance: somebody has to add new items to the dropdown, and a new line arriving in the storeroom before it is added to the form is a submission that cannot be made.
The direction, in or out, as a multiple choice with two options. Keeping direction as a separate field rather than baking it into two different forms means one log to read and one set of formulas.
The quantity, as a short answer. Short answer questions accept data validation rules, such as a maximum character count, which keeps obvious nonsense out. What validation cannot do is check the number against the stock on the shelf, because no question type reads existing data.
Who, which is best taken from the account rather than typed. A form can collect email addresses either as verified, taken from the signed in Google Account, or as responder input, which is whatever the person types. Verified is the difference between a log that settles arguments and one that starts them.
Why, as a short free text field for the job number, the customer, or the reason for a write off. This is the field people leave off and want six weeks later.
Google Forms offers twelve question types in total: short answer, paragraph, multiple choice, checkboxes, dropdown, file upload, linear scale, rating, multiple choice grid, checkbox grid, date, and time. A movement form needs three of them. Resist the rest, because every extra field is time standing in a storeroom holding a box.
Reading stock back out of the log
Once movements are rows, current stock is arithmetic. The pattern that holds up is a separate sheet with one row per item, an opening count taken at a known date, and a formula that sums the movements in and subtracts the movements out for that exact item string. Nothing on that sheet is typed by hand except the opening counts and the item list.
Two properties of this arrangement are worth appreciating, because they are the reasons to prefer it to a stored running total.
It is auditable. When the figure is wrong, the movements are all still there, so the wrong or missing submission can be found. A stored running total that has been edited by four people over three months cannot be reconstructed at all.
It is correctable without rewriting history. A movement entered as sixty instead of six gets fixed by recording a correcting movement, or by flagging the bad row, rather than by adjusting a total and hoping nobody was relying on it.
Capacity is not a concern. A spreadsheet holds up to 20 million cells or 100MB. A ledger with eight columns and two hundred movements a day uses under half a million cells in a year, so a single log can carry several years of a busy storeroom without any archiving scheme at all.
The recount is the discipline that makes the whole thing trustworthy. Physical counts drift from any ledger, because breakages, samples, and quiet borrowings do not get submitted. A periodic count that writes a fresh opening figure and a dated adjustment row keeps the calculated number honest. Without it, the arithmetic is perfect and the answer is still wrong.
The four places a form runs out
None of what follows is a fault in the form. They are properties of the category, and knowing them in advance is the difference between a system that gets abandoned in month four and one that gets extended deliberately.
The form cannot show the person what is left. No question type reads existing data, so the screen the storeman is looking at cannot say nineteen in stock. The person taking six units has no way to know that four were taken an hour ago by somebody else. Every consequence of that, from the surprise empty shelf to the double reorder, follows from this one limitation.
Nothing stops an impossible submission. Data validation checks the shape of an answer, not its truth against a stock figure, so a request for twelve units of an item with three left goes through without complaint. The negative appears later in the calculated sheet, long after the person who caused it has driven away.
Items cannot close themselves. A dropdown option stays selectable when the item is gone. For a storeroom this is an annoyance. For anything with a genuine cap, an order form for limited stock, a sign up for twenty places, it is a real problem, and it is why so many teams end up watching the responses and editing the form by hand.
The shortage report goes nowhere. Somebody submits a movement noting that the shelf is empty. The form records it, and then the log sits there. Nobody is assigned, nothing tracks whether the reorder was raised, and the person who reported it gets no reply. The whole second half of the job, the part where a human does something about what arrived, is outside the form entirely.
Low stock alerting is where teams usually patch the first of these with a script, and scripts have published ceilings. Email sends are capped at 100 recipients per day on a consumer account and 1,500 per day on a Google Workspace account. Total trigger runtime is capped at 90 minutes per day on consumer accounts and 6 hours per day on Workspace. Any single execution is limited to 6 minutes. A nightly low stock digest sits comfortably inside all three. A script that mails a supplier contact on every movement does not, and the failure is silent.
What each part of the job needs
| Part of the job | Form plus spreadsheet | What it would take otherwise |
|---|---|---|
| Recording a movement from the floor | Fits well, a phone and three fields | Nothing better exists at this price |
| Keeping a movement history for audit | Fits well, append only by design | A database table |
| Answering what is on the shelf now | Calculated, correct, one formula | Same |
| Showing the remaining count while submitting | Not possible | A tool whose form reads data |
| Refusing a quantity that is not available | Not possible | Stock aware validation |
| Closing an item when it runs out | By hand, by editing the form | An automatic cap |
| Assigning who chases a reorder | An extra column, kept by hand | An owner on the record |
| Replying to the person who reported a shortage | A separate mail client | A send box beside the record |
| Counting stock across two locations | Extra column, formulas per location | Same, or a real inventory system |
Read the table as two blocks. The top four rows are the job a form does well, and for a single storeroom with one person responsible, they may be the whole job. The bottom five are all versions of the same gap: the form finishes when the submission lands, and the work does not.
Deciding which problem you actually have
Three different pains send people to this search, and they have three different answers.
If the pain is the clipboard, that movements are not being recorded at all or are typed up days late, a form solves it outright. Build the movement ledger, keep it to five fields, and stop.
If the pain is the count being wrong, the answer is usually not a new tool. It is a recount schedule and a dropdown instead of typed item names, because inconsistent item strings and missing physical counts cause more wrong numbers than any software limitation.
If the pain is what happens after a submission, that shortages get reported and nothing visibly happens, that two people ordered the same part, that nobody replied to the person who flagged it, then more spreadsheet work will not help. That is the shape of the tool rather than the state of the setup, and it is the point at which a form tool with response management earns its keep: the submission arrives already carrying an owner and a stage, the reply is sent from the same screen as the answers, and unlimited forms and responses are priced by the number of people using it rather than by how much gets recorded, which suits a log that grows every day.
What to change first
Split movements from stock levels: let the form record only what moved, and calculate the shelf figure from those rows rather than storing it. Then set a recount date, because arithmetic on an incomplete log is confidently wrong. If the reorders and the replies are the part that keeps slipping, the use cases page shows what the same submissions look like with an owner and a status attached, and Halict can be tried against a real form before anything is migrated.
Q1. Can a Google Form subtract from a stock count automatically?
Not on its own. The form appends a row for each submission, and the current stock figure has to be calculated from those rows in the spreadsheet, using an opening count plus the movements in minus the movements out. Storing a running total that the form overwrites is possible with a script but loses the audit trail, which is the main advantage of the arrangement.
Q2. Can the form show the person how many units are left before they submit?
No. None of the twelve question types reads existing data, so the form cannot display a live stock figure or refuse a quantity larger than what is available. The shortfall shows up later in the calculated sheet. If the person submitting needs to see the remaining count, that requires a tool whose form can read from its own records.
Q3. How many movement rows can a spreadsheet hold before it becomes a problem?
A spreadsheet allows up to 20 million cells or 100MB. At eight columns per movement, that is far more than a busy storeroom generates in several years. Slowness usually arrives long before the cell limit does, and it is normally caused by formulas that recalculate across the whole log rather than by the number of rows.
Q4. Should items be a dropdown or a typed field?
A dropdown, in almost every case. Typed item names arrive in several spellings, and every variant is a separate item to the formulas that add up movements, which is the most common cause of a stock figure that will not reconcile. The cost is that somebody has to add new items to the form before they can be recorded.
Q5. Can the form email somebody when stock falls below a threshold?
Yes, with a script on a time driven trigger, within published quotas: 100 email recipients per day on a consumer account, 1,500 on a Google Workspace account, total trigger runtime of 90 minutes per day on consumer accounts and 6 hours on Workspace, and 6 minutes per single execution. A nightly digest fits easily. Mailing on every individual movement is the pattern that runs out of quota without warning.