Why project material is different
In a warehouse, material moves against orders and SKUs. On a project, material moves against work — a specific task on a specific job. The steel issued today is not “stock out” in the abstract; it is the plate for the cutting task on the skid project, and unless the issue records which task it was for, the project can never know what it actually consumed. That single requirement — material keyed to a task — is what separates real project material management from a stores register that just tracks quantities in and out.
It matters because material is usually the largest single cost on a project, and the place margins leak fastest. Steel over-issued to one task and never returned, consumables drawn without a reference, a hired item booked to the wrong job — each is invisible unless issue is tied to the task the Bill of Resources planned it against. Tie them together and the planned consumption and the actual consumption sit side by side; leave them apart and material cost is a mystery until the accounts close.
The plan-to-actual material chain
Project material management is a chain that starts in the plan and ends in the actual cost, with procurement and stores in between. Each link keys to the project and task so nothing is lost at a boundary.
The first link is the plan: the material lines in each task’s Bill of Resources say what the work should consume. From there a project purchase requisition raises what must actually be bought — the gap between what the plan needs and what stock is already on hand — which feeds procurement. Received stock lands in the store, and from the store it is issued against the task. Only at the issue step does planned consumption become actual, and only because the issue carries the task reference all the way through.
Issuing stock against a task
The issue is the moment that matters. When a storekeeper draws plate, wire or consumables from the store against a task, three things happen at once on the same engine: stock falls in inventory, the task accumulates real material cost, and the planned Bill of Resources line gets its actual counterpart. There is no separate re-keying into a costing sheet, because the store movement is the cost entry — the same store and inventory engine that runs the warehouse runs the project issue.
That shared engine is what makes the numbers trustworthy. Because issue, stock and project cost are one transaction, the task’s actual material cost is always current, the store’s balance is always right, and a query like “how much steel has this project consumed so far?” has a real answer at any moment — not one that waits for a month-end stock count. It is also the material half of budget-versus-actual tracking: the actual cost that sits next to the budget comes largely from here.
See stock issued against a live task
We can show you a project PR, a store issue against a task and the actual material cost landing next to the planned Bill of Resources, in a 30-minute demo on your own job.
Planned vs actual material
With issue tied to the task, reconciliation stops being an exercise and becomes a report. Each task shows what its Bill of Resources planned to consume against what was actually issued, and the gap tells a story: a task well over its planned material may be over-ordering, scrapping, or absorbing scope it was not quoted for. Caught during the job, that is a question you can ask the site while there is still material to save; caught at handover, it is a loss already booked.
Reconciliation also protects the next quote. A shop that sees, job after job, that a certain task always consumes 15% more plate than planned can fold that into its next estimate — so the plan converges on reality instead of repeating the same optimistic error. Material reconciliation is not just control of today’s project; it is the data that sharpens tomorrow’s Bill of Resources.
What generic project tools cannot do
This is the capability generic project software structurally cannot offer. A task-list app with a Gantt has no store, no stock ledger and no concept of issuing material against a task — so it can plan that a task needs steel, but it can never tell you what the task actually consumed, because the material lives in a different system it does not talk to. The link between a project task and real inventory movement only exists when both run on the same engine. That is why project material management is a genuine differentiator: it is the join between planning and the physical stock that a bolt-on scheduling tool cannot make.
How Fast Project Software manages project material
Fast Project Software runs project material on the shared Fast Suite store and inventory engine, so the chain is unbroken. Material is planned in each task’s Bill of Resources from the shared item master; a project purchase requisition raises what must be bought and feeds Inventory & Procurement; received stock is issued from the store against a specific task; and that issue simultaneously reduces stock and posts actual material cost to the task — turning the planned BOR into actual consumption and feeding budget-versus-actual. Because it is one engine keyed to the project and task, nothing is re-keyed and a project’s material spend is a live number. It suits construction, EPC, ETO and fabrication teams; pricing is indicative and in INR — see pricing.
Frequently asked questions
What is project material management?
Project material management is the practice of getting material to project work and knowing what each task actually consumed. It runs as a chain: material is planned in each task's Bill of Resources, a project purchase requisition raises what must be bought, received stock lands in the store, and stock is then issued from the store against a specific task. Because each link keys to the project and task, planned consumption becomes actual material cost — unlike a plain stores register that only tracks quantities in and out.
What does it mean to issue stock against a task?
Issuing stock against a task means that when material is drawn from the store, the issue records which task on which project it was for. On a shared engine, that single movement does three things at once: it reduces inventory, it posts real material cost to the task, and it gives the planned Bill-of-Resources line its actual counterpart. Because the store movement is itself the cost entry, there is no separate re-keying into a costing sheet, and the task's actual material cost is always current.
How does issuing material turn a plan into actual cost?
The Bill of Resources plans what a task should consume, but that is only a plan until material actually moves. When stock is issued from the store against the task, the planned material line gets an actual counterpart at the real quantity and rate. Do that for every issue and each task shows planned versus actual material side by side. Because issue, stock and project cost are one transaction on the same engine, the project's material spend is a live number rather than a month-end reconciliation.
What is a project purchase requisition?
A project purchase requisition (PR) is the request to buy what a project needs but does not already have in stock. It is driven by the material planned in the tasks' Bills of Resources, netted against what is on hand, and it feeds procurement. Keying the PR to the project keeps the buy side connected to the plan, so purchasing serves the actual work rather than generic stock replenishment, and the material bought can be traced back to the tasks that required it.
Why can generic project tools not manage project material?
A generic task-list or scheduling app has no store, no stock ledger and no concept of issuing material against a task, so the material always lives in a separate system it does not talk to. It can record that a task needs steel, but it can never tell you what the task actually consumed. The link between a project task and real inventory movement only exists when planning and stock run on the same engine, which is why store-issue-against-a-task is a capability bolt-on scheduling tools structurally cannot offer.