Internal Stock Tracking and Requisitions Made Easy

If your organisation runs an internal stores depot — supplying your own staff with stationery, PPE, cleaning supplies, maintenance tools, or any other consumables — and your current system is a combination of email, paper forms, and a spreadsheet that someone updates when they remember, then this guide is for you.

We're talking about councils, hospitals, schools, mining services, building-services companies, and any other small or medium organisation where staff draw from a shared internal stock room. The Frostbyte Pro team has spent the past year building this exact workflow with one customer in particular — a New Zealand council — and most of what's in this guide comes from real conversations with their finance manager, their stores team, and their procurement auditor.

The good news: this doesn't have to be complicated. The bad news: most general-purpose inventory systems treat internal requisitions as an afterthought, which is why finance teams end up keeping their own parallel spreadsheets.

This is a practical guide to what a requisition system should actually do, and what to look for if you're shopping.

The Problem with Spreadsheets and Email

Most organisations start the same way. A staff member needs gloves from the depot, so they email their manager. The manager replies "approved", forwards it to stores, and stores eventually pulls the gloves from the shelf and emails back confirming. Somewhere, ideally, someone writes it down — but probably they don't.

This works fine when the volume is low. It stops working when:

1. Finance asks for a breakdown of consumables spend by team. Now someone has to dig through twelve months of emails and reconstruct what happened. This usually takes a week and the numbers never quite tie.
2. An auditor asks "who approved this purchase and when?" for a specific item. The answer is either "I don't remember" or "let me look through my sent items".
3. A manager wants to know how much budget their team has left. There is no way to answer this without a manual count.
4. Stock starts running out at the depot. Nobody is tracking what was issued, so re-order points don't trigger and you discover at the worst possible moment that there are no hi-vis vests for the new starters.
5. Someone leaves the organisation. Their inbox is archived and three years of approval history disappears with them.

The fundamental problem is that internal stock movements are transactions, but spreadsheets and email treat them as messages. Transactions need an immutable record. Messages get deleted.

What a Requisition Workflow Actually Looks Like

Strip away the jargon and an internal stock requisition is a simple four-step flow:

1. Staff member raises a request. They specify what they need (line items with quantities), which team they're on, and optionally why. This is the SUBMIT step.
2. Their manager approves or rejects. If approved, the request goes to the warehouse. If rejected, the requestor sees the reason and can revise. This is the APPROVE step.
3. The warehouse picks the items from the bin. Stock is deducted from inventory. If only some items are available, partial fulfilment is recorded. This is the PICK step.
4. The requestor (or a delegate) physically receives the items. Finance gets the audit trail. This is the ISSUE step.

That's the entire happy path. Most requisitions move through these four steps in under 48 hours. The branches handle the messy edge cases: rejected (terminal, with a reason), cancelled (before pick), partial fulfilment (split across two issues if needed).

The trick is that every transition needs to be recorded — who did what, when, and why. Not in their email; in the system.

Five Things to Look For in a Requisition System

If you're evaluating software, here are the five things that separate a real requisition system from a glorified shopping cart.

1. First-Class Cost Codes (Not Tags)

Every requisition needs to be attributable to a cost code — the GL line where the spend lands. A real system makes cost codes a first-class entity, not a freeform text tag. You should be able to:

• Define cost codes once (e.g. PARKS-OPS, ROAD-CAP, ADMIN-OPS).
• Map each one to a Xero account code (e.g. 5200, 5300) for auto-posting.
• Run a per-cost-code spend report at month end.
• Deactivate old codes without losing the historical link from past requisitions.

If the system treats cost codes as tags, you lose all of this. Two months in, someone will type Parks Ops instead of Parks-Ops, and finance will quietly stop trusting the report.

2. Strict Approval Workflow with a Self-Approval Guard

The single most important procurement audit principle is that the person who requested can never be the person who approves. This is not a UX nicety — it's a separation-of-duties control that auditors check for.

A real system enforces this on the server, not in the UI. Even an organisation owner cannot approve their own request. If the requestor is also the only available approver, the right answer is for another manager to step in, not to weaken the rule.

Look also for a strict requestor guard: only the original requestor can submit their own draft for approval. Why does this matter? Because procurement audit relies on "this person requested this stuff" being a truthful claim. If a manager can submit on behalf of a junior staff member, the audit chain breaks.

3. First-Class Partial Fulfilment

Real life isn't tidy. Sometimes the warehouse only has 12 of the 20 hi-vis vests that were requested. A real system treats this as a normal case, not an exception:

• The request stays at the full requested quantity.
• The pick records the actual picked quantity.
• The "issued" column shows both numbers (e.g. 12 of 20, with a partial indicator).
• Reports value the partial amount, not the requested.
• The requestor knows they are still short eight vests and can raise a follow-up.

A weak system forces the requestor to reject, edit, and resubmit. Apart from being annoying, this destroys the audit trail — the original record of what was requested is lost.

4. Per-Team Budget Caps with Hard Block

If your organisation cares about budget control (and finance always does), the system needs to enforce caps at the point of submission, not at the end of the financial year.

A real per-team budget feature:

• Lets admins set a cap per team per period (e.g. parks maintenance: $12,000 annual).
• Calculates "committed spend" by adding up everything already issued plus everything in-flight (submitted, approved, picked but not yet issued).
• Blocks a new submission at the server when the request would push committed spend past the cap.
• Shows the team's live consumption alongside the cap on a dashboard so the requestor sees the gauge before they submit.

The hard-block is the key bit. Soft warnings get ignored. A submission that the server refuses to accept is one that never lands in the finance year-end spreadsheet.

Look for two engineering details when evaluating: (a) the cap check should run inside a database transaction with serializable isolation — otherwise two concurrent submissions can both squeak in just under the cap, and (b) team matching should be case-insensitive so "Parks" and "parks" can't both bypass the same cap.

5. Append-Only Event Log

Finally — and this is the one most general-purpose systems get wrong — every status transition should write to an append-only event log. Not just a "last modified" timestamp. The full sequence:

Created       — by Ana, at 10:42 on 2026-05-12, with these line items
Submitted     — by Ana, at 11:05 on 2026-05-12
Approved      — by Pita, at 14:20 on 2026-05-12
Picked        — by Marama, at 09:15 on 2026-05-13, quantity 12 of 20
Issued        — by Marama, received by Ana, at 09:30 on 2026-05-13

Each row is immutable. Together they let finance reconstruct exactly what happened, in what order, with whose authorisation. If a budget cap was changed mid-flight, the audit log records the cap as it stood when each submission was checked. If an approver later left the organisation, their decisions are still there.

This is event-sourcing applied to internal stores. It's the audit trail procurement and finance teams need, without anyone having to remember to keep it.

Why Xero Auto-Post Changes the Game

If your organisation already uses Xero (most New Zealand small and medium organisations do), the single highest-leverage feature a requisition system can offer is automatic journal posting when goods are issued.

Here's the workflow:

• You map each cost code to a Xero expense account (one-time setup).
• You set a single inventory asset account on your organisation (also one-time, e.g. account 1300).
• When a requisition is marked ISSUED, the system automatically posts a balanced manual journal to Xero: the cost code's expense account is debited, the inventory asset account is credited, the SR number is in the journal narration so finance can trace it both ways.

This eliminates the entire "month-end reconciliation" routine. Your Xero balance sheet reflects current depot stock value continuously. Cost of internal consumables flows automatically to the right P&L line. Finance never has to copy a number out of a spreadsheet and paste it into Xero.

The mechanical details matter though. Look for:

• Idempotency: if the auto-post fails or retries, no duplicate journal lands in Xero.
• Skip-not-error behaviour: if Xero isn't connected, or a cost code is missing the Xero account mapping, the SR still issues cleanly — the journal is just skipped (and surfaced for manual retry later).
• Multi-line aggregation: if a requisition has multiple cost codes, the journal aggregates DR lines by account so the entries match how finance reads a journal.

Reports Finance Actually Runs

Once the system is running, three reports cover 90 percent of what finance asks for at month end:

1. Spend by Cost Code. Total cost per code in the period. Used for finance month-end allocation and Xero reconciliation.
2. Consumption by Team. Which teams drew the most stock. Used for team-budget reviews and capacity planning.
3. Top Consumed Products. The products running through the depot fastest. Used as a restocking signal.

All three should filter on the receipt date (when goods physically left the depot), not the request creation date — because that's when finance books the cost. Note that this differs from how budget consumption is calculated (which uses request creation date to track commitment-when-raised). Both are correct, in their own context. Make sure the system's UI explains the difference, because users will otherwise assume the numbers should tie.

CSV export from each report is essential. PDF export is a nice-to-have for the monthly finance pack.

How to Implement This in Your Organisation

If you're starting from scratch, here's a sensible rollout sequence:

Week 1: Set up the foundations

• Define your cost codes (start with 5–10 — you can add more later).
• Map each code to a Xero account code if you use Xero (talk to your accountant if you're not sure which one).
• Set the organisation's Xero inventory asset account.
• Define your teams (just the strings used on requisitions — no need for a separate team-management system at this stage).
• Set initial per-team budgets if you want budget controls from day one (you can also defer this and add later).

Week 2: Seed the catalogue

• List the items the depot stocks (stationery, PPE, cleaning, maintenance, tools).
• Assign each to a cost code if you want auto-charge defaults.
• Set bin codes so warehouse staff know where to pick from.
• Enter opening stock counts.

Week 3: Pilot with one team

• Pick a single team — somewhere with high volume and a friendly manager.
• Have the team raise real requisitions through the system.
• Have managers approve through the system (no parallel email).
• Have the warehouse pick and issue through the system.
• Run the first month-end report. Reconcile against finance's existing spreadsheet to confirm numbers tie.

Week 4: Roll out to remaining teams

• Once the pilot team's manager and warehouse are comfortable, expand to the rest.
• Stop accepting email-based requests at this point — the system is the single source of truth.
• Schedule a 30-minute training session for each new team.

The whole thing should take a month, end-to-end. If it's taking longer, the system is probably overcomplicated for your actual needs.

A Final Word on Cost

Internal requisition systems get sold to enterprise customers as part of larger procurement suites costing tens of thousands per year. You don't need that. A modern cloud system with all the features in this guide — cost codes, approval workflow with self-approval guards, partial fulfilment, per-team budgets, Xero auto-post, and a full audit trail — should cost the same as any other modern SaaS inventory product. In NZD, that's roughly $90–400 per user per month depending on the vendor.

If a vendor quotes you significantly more than that for the same feature set, they're charging you for enterprise overhead you don't need. If a vendor quotes you significantly less, check whether they actually have the audit trail and Xero integration; "requisitions" as a buzzword on a feature list doesn't mean the system can survive a procurement audit.

If you'd like to see what a complete internal-stores workflow looks like end-to-end, the Frostbyte Pro requisitions demo walks through a real New Zealand council scenario — staff request, manager approval, warehouse pick, partial fulfilment, audit trail, Xero auto-post, and per-team budget caps — in about ten minutes. There's no signup required.

Whatever you choose, get the foundations right: cost codes as entities (not tags), strict approval workflow, partial fulfilment as a normal case, hard budget caps, and an append-only audit trail. Get those right and the system will pay for itself in finance hours saved within the first quarter.