One approved chain, from requirement to reconciliation.
The estimate already says what the project needs and when. From there it is nine screens — indent, quotation, order, gate, store, vendor bill — each one moved by a person whose name stays on the record. The last screen tells you, in rupees, what the site could not account for.
Every step hands the next one its numbers. Nothing in this chain is typed twice.
Nine screens, and each one is the next one's paperwork.
Most site offices already do all nine things. They do them on WhatsApp, in a diary and in three spreadsheets, so no two of them agree at the end of the month. Here the indent becomes the order, the order becomes the receipt, the receipt becomes the vendor bill, and the bill becomes the reconciliation — with the same quantity carried the whole way.
What to buy, how much is left to buy, and the last date to order it.
Every measured item carries a consumption formula, so the project's material demand is already known — 50 cum of M25 is 380 bags of cement, not a guess. The procurement screen puts that demand beside what has already arrived and what is already on order, and works out the balance for you.
| Column | Where the number comes from |
|---|---|
| BOM | Consumption formula × measured quantity, across the whole project tree |
| Received | Every supplier invoice and GRN entered at the gate |
| On order | Outstanding quantity on purchase orders that are approved, sent or part delivered |
| Balance | BOM − received. What still has to come to site |
| Need by | The earliest planned start among the activities that use it and are not finished |
| Order by | Need-by date minus that material's lead time in days |
Lead time is kept per material and can be set for one project or for the whole company. Cement at 3 days and a lift at 90 days are not the same problem, and the order-by date is what tells you which one is urgent today.
Where the requirement is worked outFive words instead of a spreadsheet
Each material is given one status, and the list sorts itself so the trouble is at the top.
A material bought on an ad-hoc indent — diesel, consumables, anything the estimate never budgeted — still appears here with its orders and receipts. It simply has no BOM line to be measured against, and it is never wrongly flagged as over-budget.
Month by month, so you can plan the cash
Beside the list is a month-wise matrix: how much of each material the programme needs in March, in April, in May. Filter it by sub-project, by stage, by category, or to a date window, and the requirement re-spreads over exactly those weeks.
Tick the materials you are short of and the screen raises the indent for them, with the quantities already filled in.
Nobody buys anything until somebody approves it.
The site raises an indent. It does not become an order because the storekeeper rang the supplier — it becomes an order because it was approved, and the app knows who approved it and when.
Instead of approving it, the same screen can reject it — and a rejected indent goes back to draft to be corrected and sent again.
What each move actually does
An indent that is deleted is not gone — like everything else in the app it is snapshotted into the Recycle Bin with all its items, and can be restored.
The slip the store can actually hold
Every indent prints as an indent slip — the number, the date, the needed-by date, the stage, every material with its quantity and unit, the remarks, and signature blocks. A draft prints with a DRAFT watermark across it, so an unapproved slip cannot be passed off as an approved one.
All the indents on a project come out together as an indent register in Excel, with each indent's status shown, for the meeting where somebody asks what is pending.
Raised from the requirement, not from memory
You do not start an indent with a blank page. Tick the materials on the requirement screen — the ones showing late or order now — and the indent opens with those materials and the balance quantity already in it. You can still type in a material that the estimate never budgeted, because sites really do need one drum of diesel.
One directory, so the same supplier is not typed four times.
The vendor master is company-wide, not per project. Every enquiry, every purchase order, every receipt and every bill in this module points back to a row here — which is what makes the question "how much have we bought from him this year, and what do we still owe him" answerable at all.
- A code of its own. Each vendor gets VEN-001, VEN-002 as you add them, so two suppliers with similar names never get mixed up.
- The details that matter on a bill. GST number and PAN, contact person, phone and email, address, city, state and pincode, and the bank account with IFSC for the payment.
- Payment terms in days. Set 30 days on the vendor and every invoice you enter for him gets its due date worked out on its own. That one field is what makes the payables ageing honest.
- A category and a status. Active, inactive or blacklisted — a supplier you have fallen out with stops appearing where he should not, without deleting his history.
- A rating out of five and your own notes, so the reason you stopped using someone is written down and not carried in one person's head.
Why it is one list and not one per project
A construction company buys cement from the same three traders on every site. Keeping them in each project separately is how you end up with four spellings of one firm, three different GST numbers typed by three people, and no way to see the total exposure.
Because the directory is shared, an enquiry can go to every trader you have ever used, and the payables screen can total what you owe a vendor across all your running projects, not just this one.
And it posts into the booksCompare the three quotations side by side, then award.
Rates are usually compared on a piece of paper that nobody keeps. Here the enquiry, the three replies and the reason one of them won all sit on the same record — and the winner turns straight into a purchase order.
The RFQ moves to quoted by itself the moment the first vendor's rates are entered, and to closed when the award is made. It can also be cancelled outright.
Your vendors do not need a login
This is a site office, not a portal. The trader sends his rates on WhatsApp, on a letterhead, or on the phone — and your buyer types them in. The record is the same either way.
- Pick the materials and quantities, add the vendors you want to ask, and print or send the enquiry as a PDF. Marking it sent stamps the time against each vendor.
- For each reply record the rate and the GST percentage per item, the quotation date, delivery in days, freight, any other charges, and the remarks he made.
- Attach what he actually sent. One PDF or photo of his quotation per vendor, up to about 9 MB, kept on the record — so six months later you can prove what was quoted.
The comparison, worked properly
Not just the rate — the landed cost. Items plus GST plus freight plus other charges, per vendor, so the cheapest rate does not quietly become the costliest order.
| Landed cost | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Items as quoted | 1,90,000 | 1,86,000 | 1,92,500 |
| GST as quoted | 34,200 | 33,480 | 34,650 |
| Freight | 4,000 | 12,000 | 2,500 |
| Other charges | — | 1,500 | — |
| Landed total | 2,28,200 | 2,32,980 | 2,29,650 |
Illustrative figures, to show how the comparison is built up.
- Lowest per item is marked on every row, so you can see who is cheapest on cement and who is cheapest on steel.
- Lowest overall is only awarded to a vendor who has quoted for every item. A half-filled quotation cannot win a comparison by leaving the expensive lines blank.
- Split the award. Give cement to one and steel to another, and the app raises one draft purchase order per winning vendor, with his own quoted rates and GST already in it.
The whole comparison also exports to Excel for the file that goes to the director for sanction.
The order goes out with an approval on it, and reports its own delivery.
A purchase order here is a real document — vendor, delivery address, line items with rate and GST, freight and other charges, terms and conditions, and signature blocks. It is also a live record: nobody types "delivered" on it, because the receipts at the gate move it.
Rejecting sends it back to draft with the reason on it. A vendor has to be chosen before it can even go for approval.
- Part delivered and delivered are not choices. They are set by the receipts booked against the order, and they step back on their own if a receipt is edited down or deleted.
- Cancel is blocked once anything has been received against it — you cannot make a delivery disappear. Short-close the undelivered balance with Mark Complete instead, which is what a buyer really means.
- Signatories with a real signature. The approval carries the signature onto the printed PO, so what goes to the vendor is the document that was actually approved.
The over-budget flag — a warning, never a barrier
Before an order is saved the app checks each material against what the project still has left to buy:
remaining = BOM − already received − already on order
Order more than that and the PO is flagged as over budget, with the material and the remaining quantity named. It still saves — a site sometimes has to buy more than the estimate allowed, and software that refuses just gets bypassed. But now the excess is visible on the day it is committed, and not at the end of the job.
A material the BOM never budgeted is not flagged at all. There is nothing to compare it against, and a false warning is worse than none.
What is still to come
Every open order carries an outstanding quantity — ordered minus received, line by line. That is the figure the requirement screen calls on order, which is how the app knows you do not need to buy the cement again this week.
The whole project's orders export as a register in Excel, and any single order prints as a PDF for the vendor.
Two doors, and which one you use decides whether the order knows.
Material arrives two ways on a real site: against an order, and as a cash bill somebody fetched because the work could not wait. Both are recorded — but only one of them is a GRN.
Receive against a purchase order
Pick the order and the form fills itself: the vendor, and every ordered material with its ordered, received to date and outstanding quantity. "Receive now" starts at the outstanding quantity and the rate starts at the order's rate — so a full delivery needs no typing at all. You only touch the lines that came short.
Saving gives it a number — GRN-001, GRN-002 — running per project, and the order's delivery status moves by itself.
Or a direct purchase, with no order behind it
A cash bill, an urgent local buy. Enter the vendor, the invoice number and date, and the materials with quantity and rate. It goes into the same register and counts as received — but it gets no GRN number and touches no order.
The register tags every row PO or manual, so at a glance you can see how much of your buying actually went through an order.
The challan does not go missing any more
Photos or a scanned PDF attach to the entry, several at a time, up to 10 MB each. They show as thumbnails you can drop before saving, and the register carries a paperclip on any row that has them.
The site team can do this at the gate from the phone, with the photo GPS-stamped, and it reaches the store and the reconciliation the same day.
How the site app records itThe Goods Receipt Note
Every receipt prints as a GRN for the gate file: the GRN number, the order it is against — or "direct receipt, no PO" — the vendor, invoice and challan details, then every material with:
| Material | PO qty | Recd to date | This receipt | Amount |
|---|---|---|---|---|
| Cement OPC 53 | 120 | 80 | 80 | 30,400 |
Then the receipt value, the number of photos attached, your remarks, and three signature lines — Store, Checked, Approved.
Honestly: nothing stops you receiving more than was ordered. Type 130 against 120 and it saves, because that is what came. The outstanding simply reads zero and the order shows delivered.
Stock is not a number somebody maintains. It is worked out.
There is no stock figure to edit, and therefore none to get wrong. The balance of every material is derived from the documents themselves, every time you open the screen:
stock = received + transferred in − transferred out − issued
Cancel a receipt, correct an issue, delete a transfer — the balance corrects itself, because there was never a second copy of the truth to update.
- Value at what it actually cost. The rate is the weighted average of your own inward invoices, so stock value is your money, not a rate-book guess.
- Issue rates are frozen at issue time. A cement invoice that arrives next month does not quietly re-price last month's issues.
- Negative stock warns, it does not block. The storekeeper is recording what physically left the store. Refusing the entry would only push it off the books, where it helps nobody.
Issued to whom — and that is the point
An issue is booked against one of three things: a contractor, a work activity — the very item you estimated and measure against — or general site use.
Booking against the activity is what makes consumption mean something. "180 bags in March" tells you nothing. "180 bags into the first-floor slab" can be checked against what that slab should have taken.
Material issued to a contractorTransfers between your own sites
A site-to-site transfer is a paired document, not a purchase. Stock leaves the sending site the moment the truck goes — it sits in transit — and only lands at the receiving site when somebody there actually receives it.
So the same fifty bags are never counted at both sites at once, and material that never arrived stays visible as in transit instead of quietly vanishing.
Issue slips and transfer notes print for signature; the stock register and the issue register export to Excel.
What you owe, to whom, and since when.
The vendor's bill is the vendor's document. It is entered when it arrives — not drafted for him by the app when the material was received — and it can be linked to the purchase order and to the GRNs it covers, so three papers that should agree are held together.
- The due date works itself out from the vendor's payment terms. Thirty-day terms and an invoice dated the 4th is due on the 4th of next month, without anyone counting.
- Paid and part-paid are never typed. They are worked out from the payments recorded against the bill — so deleting a payment re-opens the invoice by itself, and no bill is ever marked paid because somebody forgot to change it back.
- Ageing runs on the due date, not the invoice date. A bill on thirty-day terms is not overdue on day one, and pretending otherwise makes the whole report useless.
- An advance to a vendor is recorded as a payment against no particular bill, and sits on his account until it is set off.
The approval ladder on a bill
Per vendor you get invoiced, paid, balance, what is overdue and how old the oldest item is. A payment voucher prints for the payment, a vendor statement prints for the vendor, and the whole payables position exports to Excel.
The question the whole chain exists to answer.
You bought 400 bags. The work you have billed should have used 380. Five are lying in the store. Where are the other fifteen — and what are they worth? This screen does that arithmetic for every material on the project.
The four numbers it needs
Wastage is received − consumed − site stock, the percentage is measured against what was consumed, and only the wastage above the permissible figure is turned into money. A negative wastage is shown in green as a saving, and is never charged to anybody.
- The rate used is the weighted average of your own invoices for that material — what the stock really cost — falling back to the rate book only if nothing has been bought yet, and saying which one it used.
- Reasons are recorded against each material — spillage, transit loss, theft — one line each, so the recovery conversation has something written behind it.
- Typing changes only the screen. Nothing is stored until you press Save entries.
Fifteen bags, and ₹1,440 of them are recoverable.
50 cum of M25 slab concrete billed in the first client bill. The formula on that item gives 7.6 bags of cement per cum.
| Step | Working | Figure |
|---|---|---|
| Theoretical consumption | 50 × 7.6 | 380 bags |
| Received till date | from the invoices | 400 bags |
| Should-be stock | 400 − 380 | 20 bags |
| Site stock, counted | by the storekeeper | 5 bags |
| Wastage | 20 − 5 | 15 bags |
| Wastage % | 15 ÷ 380 | 3.95% |
| Permissible | your allowance | 3.00% |
| Excess | 0.95% of 380 | 3.6 bags |
| Recoverable at ₹400 a bag | ₹ 1,440 | |
One material, one month. Run it across cement, steel, sand and tiles on a live job and it stops being small.
Say the honest part out loud
Consumption is worked out from what you have billed, not from what you have executed. So raise the bill first and reconcile after, or the consumption will look too low and the wastage too high.
It reads client running-account bills that are linked to measured items. A lump-sum bill, or an extra item with no measurement behind it, gives no consumption — because there is no honest way to work it out.
The reconciliation statement it printsMaterial is where a construction business quietly loses money.
Nobody steals a building. Material goes in ones and twos — a few bags issued against nothing, a delivery that came fifteen short and was signed for in full, an order placed on the phone at a rate nobody compared, a bill paid twice because two people were chasing the same vendor. Each one is too small to argue about, and by the end of the job they add up to more than the profit on it.
None of that survives a chain where every step has to be moved by somebody. The indent names who asked and who approved. The comparison names who was cheapest and who was awarded. The order names who sanctioned it, and refuses to be cancelled once a delivery has been booked against it. The GRN names who received it and how much. The bill is checked against the order and the receipt before it is passed. And the reconciliation, at the end, names the material and the amount that nobody can explain.
That is the whole idea. Not to catch anybody — most shortfall on a site is genuine wastage — but to make every step attributable, so the conversation is about a number instead of about a memory.
Every state above is entered by a person, and the app writes down which person and when. That is all an audit trail is.
None of this is extra work. Your storekeeper already receives the material and your buyer already places the order. The difference is that at the end of the month, the answer already exists — nobody has to go and assemble it out of a diary.
Find out what your store cannot account for.
Thirty minutes on a call. Bring one running site's purchase bills and we will run the reconciliation on it while you watch.