Neither is lying. The two numbers answer different questions that happen to share a sentence. The site knows physical reality — what came through the gate, what went into the work, who was present this morning. The head office knows commercial reality — what was ordered, what has been billed, what has been paid.

The gap between them is structural. It is produced by the way each side records, and it would exist in an office of entirely honest people.

Different moment, different unit, different purpose#

A site record is made at the instant something physically happens. A lorry comes through the gate at eleven and the storekeeper writes it down at eleven. The purpose of that record is control: is the material here, is it the right material, can the work start.

An office record is made when a commercial obligation crystallises. The invoice arrives some days later and is entered against the order. Its purpose is money: what do we owe, to whom, by when.

Both records describe the same lorry. They are written on different days, by people with different training, for readers who need different things. Then somebody asks a question that assumes they are one record.

The gaps that open on their own#

Material received, not yet invoiced. The commonest one. Stock is on site and the ledger shows nothing. At month end the site's consumption looks impossible against the office's purchases.

Invoiced, not yet received. The reverse. Money is committed and payable for material still on a lorry, still on the vendor's floor, or dispatched to another site by mistake.

Bags at the gate, tonnes in the ledger. The site counts what it can physically count. The office bills in the contract unit. Neither is wrong. Every conversion is an opportunity, and the unit of measure is where the quiet errors live.

A rate revised verbally at site. The project manager agrees a new rate with a supplier because the lorry is at the barrier and cannot wait. The order in the office still carries the old rate. The invoice will match neither.

Work certified but not billed. The engineer measures and certifies. The contractor has not yet raised the bill. The site believes a liability exists; the office cannot see it, because no document has arrived.

An advance the site does not know about. Money moved before material did, for commercial reasons that never travelled to the site. The site takes a load it believes is unpaid and treats it as a fresh liability.

Rejected material. The gate refuses a load and sends it back. If the rejection lives only in a phone call, the office has an order it thinks is fulfilled and the site has nothing.

Every one of these is an ordinary event. None requires dishonesty. Together they guarantee that two independently maintained sets of books will differ.

The reconciliation ritual#

So there is a meeting. Monthly, usually late in the month, with the site printing its sheets and accounts printing theirs.

It compares totals. That is why it fails.

Two totals differ by some amount, and the meeting now has to reconstruct, from memory and from paper, which events explain the difference. It has an hour. Some of the events are three weeks old and the man who witnessed them is at another site. So the meeting does what meetings do: it agrees a figure, records the difference as an adjustment, and moves on.

The adjustment is the damage. It closes the arithmetic without closing the cause. Next month the same class of gap opens again, because nothing about the recording changed. After a year the adjustments are themselves a body of history nobody can explain, and stock reconciliation turns into archaeology.

A reconciliation of totals can only tell you that you differ. A reconciliation of events tells you why, and the why is the only part that stops a repeat.

Two books, or one record#

The usual response is to make the site's book better — a stricter format, a weekly return, a new template. That improves one of the two divergent records. It does not stop them diverging.

What closes the gap is a change of shape: one event, recorded once, at the place and moment it happened, read by both sides.

The lorry arrives. The man at the gate records the arrival — vehicle, material, quantity as counted, condition, time — and that entry is the goods receipt note, not a transcription of the vendor's challan. Nobody re-keys it in the office. When the invoice comes, it is held against that same record rather than against a second one written later from a photograph.

Three consequences are worth stating separately.

The record is authored where the fact is known. A storekeeper knows how many bags came off the lorry. An accountant three hundred kilometres away knows what the invoice says. Asking either to author the other's fact produces a guess with a signature on it.

Nobody re-keys. Re-keying is where units drift, and it is also the moment the second version of the truth is born.

Both sides read the same row. Not a summary of it. The office should be able to see the gate entry with its time on it; the site should be able to see whether that load has been invoiced and paid.

A store run this way — the shape described in running a site store — costs the storekeeper a few minutes at the barrier and saves the monthly meeting altogether.

What is left over is real#

Even with one record, differences remain. Material genuinely in transit. Invoices genuinely not raised. A payment that has left the bank and not yet reached the vendor.

These are timing differences and they are supposed to exist. The value of recording each event once is that the leftovers are few, small and nameable — a list of items rather than a number. It is the same discipline that makes matching a bank line tractable: you are not reconciling two opinions, you are accounting for a handful of items whose timing you can state.

The short version#

Site and office differ because they record different moments, in different units, for different purposes. That is structural, not moral.

Reconciling totals hides the causes and guarantees a repeat. Reconciling events finds them. The permanent fix is to stop keeping two books: capture the event once where it happens, let both sides read the same row, and let the remaining differences be the small ones that are genuinely about timing.

The discount is not a fix. It is an agreement to keep producing a document nobody trusts.

A percentage is a judgement, not a measurement#

A quantity is measured. A percentage complete is estimated. Between those two sentences sits every problem this post is about.

To say a slab is sixty per cent done, somebody has to decide what the remaining forty per cent contains, how long it will take, and how the parts compare in effort. That is a forecast wearing the clothes of an observation. It looks like data on the report because it has a number in it.

And it is a forecast made by a particular person: the one who will be questioned if it is low. Nobody in that position is being dishonest. They are being reasonable in the way people are reasonable under pressure — the reinforcement is tied, the shuttering is nearly ready, the pour is arranged for Thursday, so the honest feeling is that this is mostly done.

Why the number only drifts one way#

Optimism in progress reporting is not random noise. It has a direction, and the direction is structural.

The reporter is the reviewed. The person estimating progress is the person whose performance is read off the estimate.

The invisible work is at the end. Testing, finishing, snagging, the services that only reveal their problems at commissioning. Early work is visible and satisfying. Late work is fiddly and easy to underestimate.

Started reads as half done. Once a trade is on site, the item stops being zero. In practice a great deal of started work sits at very little value for a long time.

Nobody is punished for correcting upward. Reporting more this week than last is comfortable. Reporting less requires an explanation, so a figure that should fall is held flat instead.

That last one produces the plateau everybody recognises. An item reaches ninety per cent and stays there for weeks, because it cannot go down and it cannot honestly go up. The plateau is not a measure of the work. It is a measure of what the reporting system will accept.

Measures that cannot be argued with#

The alternative is not a better estimate. It is a different kind of statement.

Physical quantities against the bill of quantities. Cubic metres poured, tonnes of steel fixed, square metres plastered, against the scheduled quantity. This is a count, not an opinion, and the schedule already contains the denominator — the structure is set out in reading a bill of quantities. It also has the advantage of matching the way the job will eventually be billed, so progress and money stop being two unrelated stories.

Binary milestones. Either the slab is cast or it is not. Either the lift is commissioned or it is not. A milestone that can be half achieved is not a milestone, it is a percentage with a name on it. Define milestones so the answer is yes or no, put a date against each, and record the date it actually happened rather than the date it was supposed to.

Value earned, in outline. Take the scheduled value of the work actually completed and compare it with the value scheduled to have been completed by now. That is the whole idea. There is a large formal apparatus around it and most projects do not need the apparatus; they need the comparison. Two numbers, both derived from quantities, neither of them a judgement about effort.

Photographs with a date and a location. Not decoration on the report — a record. A photograph does not claim a percentage, and it cannot be revised next week to suit the meeting. What makes it evidence rather than a picture is covered in a site photograph is a record.

The common property of all four is that they do not require the reporter to predict anything. They ask what happened, and what happened is a fact somebody witnessed.

The chain that turns a number into fiction#

Even honest estimates degrade as they travel.

The engineer rounds up a little, because the last shuttering will be up by Monday. The site in charge consolidates several such figures and rounds the consolidation up, because he does not want to report a fall on a package he knows is moving. The project head reports upward against a target he committed to. The board sees a summary of summaries.

No one lied. Each step applied a small, defensible optimism to a number that already contained one. By the fourth level the figure has no relationship to the site at all, and — worse — it cannot be audited, because there is no underlying event to check it against. You cannot verify a percentage. You can verify a pour.

This is the deep argument for reporting quantities upward rather than percentages. A quantity survives aggregation. Cubic metres add up honestly at every level and can be checked against measured and docketed quantity whenever anybody doubts them. A percentage cannot even be added up correctly without weights, and the weights are usually nobody's job.

What to change on Monday#

Three changes, in order of how much they cost.

1. Report quantities, not percentages. Let the percentage be calculated from the quantity and the schedule, by whoever wants one. Nobody types a percentage into a form again.
2. Make milestones binary and dated. Cast, commissioned, tested, handed over. Record the actual date, not the planned one, and keep both so slippage is visible without a meeting.
3. Separate reporting from judging. As far as the organisation can manage it, the person who records what happened should not be the person whose appraisal depends on it. Where that is impossible — and on a small site it often is — make the record so factual that judgement has nothing to grip: quantities, dates, photographs.

The daily record is where this either works or does not. If the site's own daily progress report already carries quantities, labour present and plant deployed, the weekly figure can be built from it rather than composed for the meeting. If the daily record is a paragraph of prose, the weekly figure will always be an opinion, however sincere.

The number we refused to print#

We build a site status screen. It reports the floor reached, what is blocking work, what material is awaited, and what falls due this week. It shows no progress percentage at all, and that is a decision rather than an omission.

Nothing in the records measures how much of a slab is done. We hold deliveries, attendance, tasks, bills and photographs, and not one of them answers that question. A figure assembled from them would have been arithmetic performed on an opinion — and it would have been read as a measurement, because a number on a screen always is.

Leaving that space empty is uncomfortable. Every screen wants a headline figure. A screen that says what it knows and then stops is worth more than one that says what it was asked for.

The short version#

Reported progress runs ahead of real progress because a percentage is a forecast made by the person being marked on it, and because every level of the chain rounds the same way.

Report what happened instead: quantities against the schedule, milestones that are yes or no, dates that are actual, photographs that carry a place and a time. Let anyone who wants a percentage calculate one. The estimate will still be optimistic. The record underneath it will not.

Somewhere in the office, three people knew. An order was placed a fortnight ago. A dispatch was confirmed yesterday on a phone call. A vehicle number came through on WhatsApp this morning. None of it reached the barrier, and the barrier is where the decision has to be made.

What happens when the gate knows nothing#

The man at the gate is in no position to refuse. He has no list, so he has no basis, and a driver who has come a long way is not going to accept "I have not been told" as an answer. Behind him a supervisor wants the material. So the default is always yes.

Everything that follows comes from that yes.

The wrong material is unloaded. Nobody at the gate can compare the load against an order, because there is no order in front of him. The mismatch is discovered at issue, weeks later, by which time it has been signed for.

A load meant for another site is accepted. Same vendor, similar material, two projects. The driver takes the nearer gate. The receiving site's stock is overstated and another site's is short, and both discover it at stock-taking.

A short load is signed as full. With no expected quantity, the only figure available is the one printed on the vendor's paper. Counting against the challan is not verification; it is transcription, which is precisely the fault that hollows out a goods receipt note.

The vehicle waits. Nobody can authorise unloading, or the crane is committed elsewhere, or the storekeeper has gone to another block. Detention and demand charges start running against the account, and the argument about who pays them happens months later with no record of when the vehicle actually arrived.

Nothing reaches the office. The load is in. The entry is in a register in a cabin. Accounts finds out when the invoice arrives, which is the wrong direction for information to travel.

The specific ways the information fails to arrive#

It is tempting to say the office should simply tell the gate. Offices do try. The failures are worth naming, because each one defeats a different fix.

Dispatch confirmed on a phone call. The purchase officer knows. He is on another call when the lorry arrives, and there is no artefact anywhere that says a load was expected today.

The vehicle number changes at the last moment. A truck breaks down, a transporter substitutes another, the number shared in the morning is not the number at the barrier. A gate instructed to check the number now has grounds to refuse a load that is entirely legitimate, which teaches everyone to stop checking the number.

A partial dispatch against a large order. The order is for a quantity the vendor will deliver over several vehicles. The gate has no way to know whether this load is the first, the fourth or a duplicate — and no running balance against which to see it.

Deliveries outside working hours. Late at night, on a Sunday, during the one hour the storekeeper is at the bank. The people who can check are absent, and the people present can only open the barrier.

Free material, samples and replacements. No order exists at all. A replacement for a rejected load is often sent with paper that references nothing, and a gate process that requires an order number cannot record it.

Direct-to-site purchases. A supervisor buys locally in cash for an urgent kaam. The material is real, the need was real, and no purchase order will ever exist. If the gate can only record what the office ordered, this load enters the site invisibly.

What the gate actually needs#

Not a system. A short, specific set of facts, available at the barrier, without a phone call.

Today's expected deliveries. For each one: vendor, material, expected quantity, order reference, and the vehicle number if it is known — marked as indicative, not as a gate condition. The gate's job is to notice a mismatch and raise it, not to enforce a number that legitimately changes.

A running balance against each open order. So that the fourth lorry against an order is visibly the fourth, and a quantity that would take the order past its total is visible as it happens, not at invoice stage.

A way to record the unexpected. This is the part most designs get wrong. A gate that can only record expected loads will turn away legitimate material or, far more often, let it in without a record. The correct behaviour is to accept and record it as unexpected — vendor, material, quantity counted, photograph, who authorised entry — and let the office resolve what it belongs to afterwards. An unmatched entry that exists can be investigated. A load that was never written down cannot.

A way to record a refusal. Rejected loads leave no trace in most sites, which means the order still looks fulfilled and the vendor's version of events is the only one that survives.

Onward travel by itself. The entry should reach the store and the office without anybody re-typing it. The register in the cabin is a real record — the practical shape of one is in a gate register people keep — but a record that stays in the cabin protects nothing until the day of the dispute.

The paper the driver carries is not the record#

The driver hands over a delivery challan. It is a useful document and it is the vendor's document: it states what the vendor says he sent, in the vendor's units, signed by the vendor's man. Its purpose and its limits are set out in what is a delivery challan.

Your record is the one your side writes, at the barrier, from what your side counted. Signing the driver's copy is an acknowledgment of receipt of a vehicle, not agreement with its contents, and the difference between those two things is the whole reason to write anything down at all. The same discipline runs through running a site store: count first, write your own figure, note the difference on both copies before the lorry leaves.

Two things we found in our own gate#

Our gate screen recorded that a vehicle had come in, and that was all it recorded. The entry wrote no material receipt, so there was nothing on our side for a supplier's billed quantity to be compared against. Nobody had switched the comparison off. There was simply never a figure of our own to compare with, and a comparison that never runs raises no alarm.

The second was the register itself. The physical book in the cabin held things our software had never held: the receiving officer's name, the challan number, the rate, the slump reading, the cube results. When we read that book in and matched it against what had reached us through the phone, the book turned out to be the better record. It had been kept faithfully for years by somebody nobody was asking.

The short version#

A lorry surprises the gate because the information that it was coming stayed in the office. The man at the barrier then has no basis to refuse, so he accepts everything.

Give the gate today's expected loads with quantities and an order balance; allow it to record what was not expected and what was turned away; and let the entry travel to the store and the office on its own. The barrier is the first place your side can state a fact about a delivery. It is also the last place it is cheap to state.

The list is not failing because the fixing is slow. It is failing because of what a snag record does not contain.

Why the list never shrinks#

No identity. A snag is a line in a document, not a thing with a number. The same cracked tile is reported by the architect on Tuesday, the client's representative on Thursday, and the facilities engineer next month, in three different wordings. Nobody can tell they are one defect, so it is fixed once and closed nowhere.

No owner. The list is addressed to "the contractor". A project at handover has many contractors, and a defect that belongs to everybody belongs to nobody. This is the ordinary mechanism by which tasks stall between people: the item is not refused, it is simply never picked up.

No location precise enough to return to. "Bathroom tile chipped" is useless in a building of identical bathrooms. The man sent to fix it has to find it first, and if he cannot, he fixes the nearest plausible one.

No evidence of the original defect. Three weeks later the fixer says it was always like that, or that it was damaged after his work. Without a dated photograph of the defect as first seen, this is one person's word against another's, and it is usually settled by whoever is more senior rather than by whoever is right.

No closure test. "Done" is a message. Somebody says it is done, the line is struck through, and nobody looked. At the next walk the same item reappears and the list has lost the little credibility it had.

No state between open and closed. A snag waiting for material, a snag disputed, a snag that cannot be reached until scaffolding returns — all of them sit in the same "open" bucket as a five-minute job, so the count tells you nothing about what is actually blocked.

Four different things wearing one name#

Treating every line as "a snag" is why the list feels endless. There are at least four categories, and they need different handling and different money.

A defect. Work that was done and done wrongly. The contractor fixes it at his cost. No argument in principle, only about whether it is a defect.

Incomplete work. Not defective — absent. A socket that was never installed. This is not snagging at all; it belongs against the original scope and against the bill, and putting it on a snag list disguises the fact that the work is not finished and should not have been offered for handover.

Damage caused by another trade. The painter marks the finished floor, the plumber cuts the finished wall. The defect is real and the party who must fix it is not the party who owns the element. Without a category for this, the tiler is asked to redo work he did correctly, and he refuses, and the item sits.

A change the customer wants. Not a defect. A different colour, a socket moved. It has to leave the snag list and enter the variation process with a price, otherwise the list becomes the route by which unpriced scope enters the job at the end.

Recording the category at the moment of raising costs nothing and decides who pays, which is the argument that would otherwise happen twice.

The second walk, and the third#

Re-snagging is normal and should be designed for, not treated as failure.

The first walk produces the list. The second checks the fixes and finds new items, because access has changed and protection has come off. A third is common. What matters is that each walk can tell, item by item, what it is checking: a closed item being verified, an open one being chased, or something genuinely new.

That requires the snag to be the same object across all three walks. A list regenerated from scratch each time cannot do it, which is why the reissued spreadsheet grows.

Two failures deserve naming.

Closure by the fixer. The party who did the work marks it done. This is not closure, it is a claim of completion. Closure is an act by somebody else.

Closure by exhaustion. The date arrives, the list is long, and the remaining items are agreed to be "minor" and carried into a document nobody opens again. Six months later the same items arrive as complaints.

The shape that works#

One snag, one row. On that row:

• One identifier. Assigned when raised, never reused, never renumbered.
• One location. Unit, floor, room, element — precise enough that a man with the identifier and no other context can stand in front of it.
• One photograph of the defect as first seen, dated and located. What makes such a picture evidence rather than decoration is the subject of a site photograph is a record.
• One category — defect, incomplete, damage by others, customer change.
• One named owner, a person, not a firm.
• One closure photograph taken after the fix, from the same position.
• One closing party who is not the fixing party.

That last line decides whether the list closes. Everything else is bookkeeping; separating doing from accepting is what makes "done" mean something. It is the same principle that makes a handover fail or hold: somebody other than the man who produced the work has to accept it.

Why the spreadsheet gives up exactly when you need it#

A spreadsheet is fine for thirty items on one walk. It fails at the moment the list gets long, and it fails in a particular way.

Several people walk different floors on the same day and each fills a copy. The copies are merged by hand, so duplicates survive and identifiers collide. Photographs live in a phone gallery or a WhatsApp group, in neither case attached to the row. And the file has no history, so when a closed item reopens nobody can see who closed it or on what basis.

Whatever the list is kept in, the requirement is the same: a snag must be a record with a life, not a line in a regenerated document. And the list in the state it was on the day, open items named and owned, belongs in the handover file — not a clean sheet that pretends there were none.

The short version#

A snag list closes when each snag is a thing rather than a sentence: one identifier, one location, one photograph, one category, one owner, one closure photograph.

The person who fixes must not be the person who closes. And incomplete work and customer changes must be taken off the list entirely, because a list that contains four kinds of item cannot be finished — only abandoned.

The file is almost always assembled in the last fortnight of a job that took years, from documents created by people who have since left. That single fact explains every gap in it.

What it should contain, and why#

The test for each item is not "was it important during construction". It is "will somebody need it in three years, when nobody who built this is reachable".

As-built drawings. Not the tender drawings, not the good-for-construction set — the drawings as the thing was actually built, with the deviations marked. The first person to drill into a wall needs to know where the conduit actually went.

Approved drawings and the approvals themselves. The stamped set and the sanctions attached to it. Later — at resale, at a loan, at any alteration — somebody will ask what was approved rather than what was drawn. Requirements differ by state and by authority, so verify what your own jurisdiction demands rather than copying a list from a previous project.

Equipment manuals and warranty documents, with their start dates. A warranty without its start date is not a warranty; it is a leaflet. The date it begins, what it covers, what voids it, and the name of the party who honours it. That party is often the supplier, not the contractor.

Test certificates. Concrete cubes, water, electrical, lift, fire, pressure tests on plumbing. These are the evidence that the thing was verified when it could still be verified. The cube results in particular are unrepeatable — the argument about why they matter and what they actually prove is in the concrete cube test.

Commissioning records. Who started the system, on what date, with what settings, and what was observed. When a pump behaves oddly two years later, the first useful question is how it behaved on day one.

Service provider contacts. The firm that installed the lift, the one that serviced the fire panel, the electrical contractor. Names and numbers, and whose contract they sat under. It is the item most often skipped and the one most often needed first.

Meter readings at the moment of handover. Electricity, water, gas, with the date and the meter serial. This one line prevents a dispute about who owes for consumption before the handover, and it is impossible to reconstruct afterwards.

The snag list in the state it was on the day. Not a clean sheet. The open items, their owners and the agreed dates. A handover claiming there were no open snags is believed by nobody — the discipline is in a snag list that actually closes.

A signed acknowledgment of what was actually handed over. An index, signed by both sides, listing what is in the file and what is not. A file with an honest list of its gaps is far more useful than one implying a completeness it does not have.

Keys, access cards and administrator credentials. For the access control, the BMS, the CCTV. These are routinely handed to one individual and lost when he moves on.

Why it is always incomplete#

Because it is assembled at the end. That is the whole of the answer; the mechanics are worth one level of detail.

The documents were created over years by many parties. A test certificate went to a site engineer who filed it in a cabin since dismantled. A warranty came by email to a purchase officer who has left.

The people who could identify a document have gone. Somebody finds a stack of certificates in the last fortnight and cannot tell which pour they belong to, because the detail lived in the head of the man who received them.

Nobody's performance depends on it. The project is measured on completion and on cost. The file is a task assigned late, to a junior, with no authority to compel the subcontractors who hold half the documents — and those subcontractors have already been paid, or are arguing about their final bills.

The commercial pressure runs the other way. Everybody wants the handover to happen, and a missing manual is not going to stop it. The file is accepted as it stands and the gaps become somebody else's, later.

File at creation, not at completion#

There is one habit that fixes this, and it is not a bigger effort at the end.

When a document is created, file it then, in the place it will finally live, with the identifying detail attached while somebody still knows it. The cube result goes against the pour on the day it arrives. The warranty goes against the equipment on the day it is received. The as-built markup is made when the deviation happens, not reconstructed a year later.

This is not more work in total. It is the same work, done when it is cheap rather than when it is expensive, by the person who knows the answer rather than the one who has to guess it.

The practical form is an index defined at the start of the project — the sections the file will have on the last day — and a rule that every certificate, manual and approval enters its section on arrival. Then the file is already assembled, and somebody checks it instead of building it.

A copy is not the record#

There is a difference between handing over a copy and handing over the record, and it decides what the file is worth in a dispute.

A copy is a scan or a photocopy in a binder. It proves what somebody chose to put in a binder. Anybody who has assembled such a file knows how easily a page is swapped, a date corrected, a version quietly replaced with a later one.

Handing over the record means the receiving side gets the document with its provenance: when it was created, by whom, what it superseded, and evidence it has not been altered since. That is the difference between a document you possess and one you can rely on, and the mechanics are in tamper-evident documents.

It matters most for the items argued about later — as-built drawings, test certificates, warranty start dates — the pages where a small change is valuable to somebody and invisible to everybody else. A file whose contents cannot be shown to be the originals is evidence of good intent, not of fact, and what makes a handover fail usually comes down to that gap.

The short version#

The handover file is needed years after handover, by people who cannot ask anybody. Its contents should be chosen on that basis: as-builts, approvals, manuals and warranties with dates, test and commissioning records, contacts, meter readings, the open snag list, and a signed index naming the gaps.

It is incomplete because it is assembled at the end. File each document at creation instead, in the section it will finally sit in. And hand over the record with its provenance, not a binder of copies.

None of them is asking to see your system. Nobody has ever asked a builder to demonstrate software.

The question is always narrower and always the same shape: show me the decision, and who made it, on the date you say it was made. That is a smaller thing than the pile of paper most offices keep, and most offices still cannot produce it.

The four parts of an answer that holds#

A defensible answer has four parts, and it is only as strong as the weakest of them.

• A record made at the time. Not a note written afterwards describing what happened. A record whose own date sits inside the period it describes.
• An identified person. A name attached to the act of deciding, not to the act of typing. "Approved" with no author is a fact with nobody standing behind it.
• The thing decided about. The drawing, the rate, the bill, the variation — in the version that was in front of the person at the moment they decided.
• Evidence it was communicated. A decision nobody was told about is indistinguishable, later, from a decision that was never made.

Three out of four is not a partial answer. A dated approval by a named person against a document you can no longer identify is worth very little, and you will spend the meeting explaining why.

The four things that destroy a defence#

Every construction office has at least two of these.

A spreadsheet with no history. It shows today's figures. It cannot show what it said on the date in question, who changed a cell, or whether a cell was changed at all. The other side does not have to prove it was altered. They only have to observe that it could have been, and the file stops being evidence and becomes an assertion. That is the argument for records that are added to and never overwritten.

A message on a phone that no longer exists. The approval was given on WhatsApp. The handset was replaced, the chat was not backed up, the person has left. Or the chat survives and shows haan, kar do with no reference to which of the three pending items it answers. A message is a real communication and a poor record: no structure, and it lives on hardware you do not control.

A document that exists in three versions. Revision A on the site engineer's laptop, revision B in the contractor's mail, revision C printed and signed in a file nobody can find. Nothing marks which one was signed. Every version is plausible and none is authoritative, so the version produced by whoever is better organised becomes the truth.

A signature nobody can attribute. A scanned initial on the last page. It could have been placed by anyone with access to the scanner, and the page under it could have been swapped. The live question is not whether the mark is genuine but whether the document beneath it is the one that was signed, and what makes a document tamper-evident is a different discipline from collecting signatures.

Why reconstruction is worse than a gap#

When the query lands, the instinct is to make the file complete. Somebody drafts the missing minute, dates it back, gets it signed, and puts it where it should have been all along.

This converts an administrative weakness into a credibility problem, and those are not the same size.

A gap is ordinary. Records go missing, people leave, a period was chaotic. Every experienced reviewer has seen it and has a way of dealing with it.

A document contradicted by its own metadata, or by another file that survived, or by a person's memory under questioning, does something worse. It puts every other document you produce into doubt. You are no longer defending one decision. You are defending your records as a class, and you will lose that argument even where you were right on the merits.

Say the gap exists. Say what you do have around it — the payment that went out, the material that arrived, the mail that referred to the meeting. A consistent partial record supports an inference in your favour. A perfect record that appeared afterwards invites the opposite one.

What a trail costs its own keeper#

Our own audit trail is a hash chain. Each entry is bound to the one before it, so a row cannot be inserted afterwards without the verification failing.

That has a consequence we did not plan and have come to like. When we repair data by hand — a correction we authorised, for a reason we would defend — we cannot also write ourselves a tidy audit row explaining it. There is nowhere to put one that would not break the chain. So the repair is written up in a dated change log that people read, in words, instead.

A trail nobody can quietly add to is a trail that makes its own keeper accountable. It costs a little convenience, and that cost is the property.

The parts you can fix now#

You cannot build a paper trail for a query that has already arrived. You can build one for the queries that have not.

• Fix the moment of capture. The record is made when the decision is made, by the person who made it — not summarised on Saturday by somebody else from memory.
• Make authorship unavoidable. If a field can be filled without recording who filled it, sooner or later it will be.
• Keep one authoritative copy. Not a canonical folder that people copy out of. A place where the version in force is the one you open.
• Keep the sending, not only the sent thing. The date an instruction or a demand went out is more often the disputed fact than its contents.
• Make money decisions attributable to two people. Above a threshold you set, two signatures on money answers "who authorised this" before anybody asks.

Where any of this touches a filing, a certificate, a registration or a limitation period, the structure is general but the specifics are not, and they change. Verify the version in force with your own advisor rather than settling it from general reading.

The short version#

Nobody will ask to see your system. They will ask you to substantiate one decision, made by one person, on one date. That needs a record created at the time, a named author, the document as it then stood, and evidence it was sent.

The four things that destroy it are a historyless spreadsheet, a message on a replaced phone, a document with three versions, and a signature nobody can attribute. Building what an audit trail is for into the ordinary working day is what turns that query into a lookup instead of a scramble.

Almost every delay on such a project lives in the handover between two of them, and not inside either.

That is an uncomfortable thing to establish, because a delay in a handover has no owner. Ask the civil contractor and the front was ready. Ask the plumbing contractor and it was not. They are describing the same wall on the same day, and in each one's own records both are telling the truth.

Every programme is right and the set is wrong#

Each contractor prepares a programme. Each programme is internally consistent — sensible durations, correct sequence within that trade, resources that add up.

They are prepared separately, and each one contains assumptions about what the others will have done by a given date. Those assumptions are never written, because a contractor's programme is a description of his own kaam and not of yours. Put the programmes side by side and the assumptions contradict each other. Rarely by much. Usually by days, which is exactly the size that nobody escalates and everybody absorbs.

By month four the absorbed days are a month, and the discussion about whose month it is cannot be settled, because no document ever recorded who owed what to whom on which date.

Failures of sequence#

The front that was not ready. The next trade mobilises, arrives, finds the area not handed over, and stands. He has a claim for idling and you have a week gone. Nobody told him to hold, because the person who knew the front was late and the person who called the trade forward are not the same person.

The conduit that was not cast in. Electrical was to lay conduit before the pour. The pour happened. Now it is chased into finished concrete — slower, dearer, structurally unwelcome, and argued about for a month. The cost of the miss is many times the cost of the coordination that would have prevented it.

Two trades in one space on one day. Both were scheduled correctly by their own planners. Neither knew of the other. One wins the space and the other goes home, and which one wins has nothing to do with which is on the critical path.

A hold point nobody was told about. Work may not proceed past a stage until it is inspected — by your engineer, a consultant, an external party. The trade did not know, or knew and did not say, and the work is now covered. It is opened up, or accepted with a note. Both outcomes cost.

Failures of scope and material#

Damage by the following trade. The floor was accepted, then a scaffold went up on it and gouged it. Who pays turns entirely on whether anybody recorded the condition at handover. Without that record it is one man's word against another's, and the man still on site when the defect surfaces is the one who pays.

Material supplied by one, consumed by another. Ordinary on any job — the main contractor's cement used by the plastering agency, steel issued to a fabricator, shuttering lent across trades. If the issue is not recorded against a contract at the moment it leaves the store, it gets reconstructed at final bill from memory, and memory is generous in whichever direction is being asked.

Scope each party believes is the other's. The small item between two packages — the sleeve, the puddle flange, the cutout, the last two metres of a service run. Each contract's wording lets its own reader conclude it is not his. It surfaces when the work is needed, at which point it is priced as an extra by whoever will do it.

The mechanisms that actually help#

None of these is clever. They are all about writing something down before it is contested.

A written interface at each boundary. For every pair of trades that meets: who hands what to whom, in what condition, on what date. The condition carries as much weight as the date — "slab ready" and "slab ready, cleaned, levels checked, cutouts marked" are different obligations, and the difference is a week. This belongs in the contract document rather than a meeting, which is the same argument as what a work order or purchase order has to establish.

Joint inspection at handover, with a record. The two supervisors walk the area together, and the outgoing trade's condition is recorded on the day it stops being his responsibility. Photographs, and a line both sign. This one habit removes most damage disputes, because it converts them from an argument about the past into a comparison of two records.

One dated place where the sequence lives. Not each contractor's programme. One sequence held by you, which every trade reads, and which records when each handover actually happened against when it was due. The daily progress report is where the actual date comes from, if it is written to be read rather than filed.

A route for the boundary problem itself. Interface issues stall because they belong to two people, and a thing that belongs to two people belongs to nobody — the general case of why tasks stall between people. Somebody has to be able to raise it early without it reading as a complaint about a colleague, and escalation without shame is the condition that makes early raising possible at all.

The short version#

Contractors deliver their own scope competently and drop the joints between them. The delay you cannot recover is the one that belonged to two people.

Write the interface down — who hands over what, in what condition, on what date. Inspect at every handover with both sides present and record the condition. Keep one dated sequence that shows when the handover actually happened, not when it was meant to.

There is usually a company per project. There is a contracting arm that builds for the project companies. There is an entity holding land, often older than the rest. There is a partnership left over from a joint development done years ago with a family who still hold a share. Occasionally there is a company that exists because a lender asked for it.

This is the ordinary shape of the business, and each entity is there for a reason.

• Ring-fencing a project. A scheme's liabilities stay with the scheme. If one goes wrong the others are not dragged into it.
• Land arrangements. The landowner contributes land and takes a share. He will not put his land into a company that also carries somebody else's construction risk.
• Different partners per project. The investor in one tower is not the investor in the next. Separate entities let the economics stay separate.
• Lender requirements. A lender funding one project wants a borrower whose cash flows he can see, not commingled with four other schemes.

Each of these is sound. Together they produce an operating problem nobody signs up for deliberately: the business is one organisation and the records are several, and the seams show everywhere.

Where the seams leak#

Staff who work across entities. The site engineer covers two projects. The accountant covers all of them. The purchase manager buys for whoever is building. Salary sits on whichever entity was convenient at the time of joining, and time is booked nowhere at all. At year end somebody allocates by feel and calls it a policy.

Material bought on one and consumed on another. A lorry of steel ordered by the entity with the credit line, unloaded at the site that needed it. The GRN is written at the receiving site, the invoice reaches the buying entity, and the two records sit in different books with no line joining them.

One purchase order covering two projects. Cheaper per tonne, obviously. It is also a document that cannot be matched cleanly against either set of books, and three-way matching breaks on it in the ordinary way — one order, several receivers, several ledgers.

Inter-company balances nobody reconciles. Entity A has paid things for entity B for three years. A's books show a receivable, B's show a payable, and the two figures have never agreed. Nobody reconciles them because there is no counterparty pushing. Both sides are you, and neither side chases itself.

One account paying another entity's vendor. The money was in the wrong place on the day, so the payment went from wherever it could. It records as an expense in the paying entity, and the correction, if it comes at all, comes months later as a journal nobody can trace back to the bank line. It makes matching a bank line impossible in exactly the case where matching would have told you something.

One WhatsApp group for three legal persons. Approvals, rates and instructions spanning separate legal entities in a single thread, with no marker of which company any given message binds. When somebody later asks who agreed what on behalf of whom, the thread cannot answer, and the hisaab that follows is settled by whoever remembers it more confidently.

The discipline that holds#

Three habits. All cheap if adopted early and expensive if adopted late.

The entity is a field on the transaction, not a folder it lives in. Every voucher, order, receipt, bill and payment carries the entity it belongs to as data, chosen at entry by the person who knows, and it cannot be left blank. If the entity is decided later by whoever is doing the books, then it was decided by convenience, and every report by entity is a report of somebody's convenience.

Once it is a field it composes with everything else. Entity plus project plus cost head answers the questions you actually get asked, which is part of why cost heads that survive a project matter more than the chart of accounts does.

A transfer between entities is documented as a transfer. Not as an expense in one and silence in the other. Two entries, one document, one reference, each side naming the other. If it is a loan, it says loan. If it is a supply, there is a supply document. If it is a reimbursement, the underlying cost is identified.

The test is plain: can somebody who was not present tell, from the record alone, why money moved between two companies you own? If the answer is "they would have to ask", it is not documented.

Shared costs have a stated basis, decided in advance. Head office salary, a shared consultant, insurance covering several sites, a vehicle. Write down how it is split and why — area, value, headcount, whatever suits — and write it down before the period it describes, not during the review that questions it.

An allocation basis decided in advance and applied consistently is a policy. The same basis decided at year end is a result, and it reads like one to everybody who comes later.

Why the history matters more here#

With one company, an amended entry is an amended entry. With several, an amended entry may have moved a cost between two legal persons, and the question when did this become entity B's cost, and who decided that? has a real answer somebody may need.

Records that are added to rather than overwritten — append-only records — carry that answer at no extra cost. So does the habit behind what an audit trail is for: holding not only the current state but the sequence that produced it, and the person who produced it.

How the structure should be set up, and the rules that govern dealings between related entities, are matters for your own advisors, and they change. Verify the version in force with them rather than settling it from general reading. What does not change is the operating point below the legal one: the structure is a fact of the business, and the records have to be kept in a way that survives it.

The short version#

Several entities is the normal shape of an Indian developer, and each one exists for a reason. The cost is operational, and it lands on staff time, shared material, common orders and money moving between accounts.

Make the entity a required field at the point of entry. Document transfers as transfers, with both sides referring to each other. Fix the basis for shared costs before the period rather than after it.

The reason is structural rather than careless. The structure is designed for the budget. The budget is a forecast made before anything was known — before the contractor was appointed, before the soil report changed the raft, before the finishes were revised. The actuals then arrive in the shape the invoices happen to have, which is the shape of your vendors' businesses and not of your forecast.

So a structure built for one purpose is filled by data generated for another. The mismatch does not announce itself. It surfaces the first time somebody asks a question the coding cannot answer.

The grain is wrong#

A head too coarse to be useful. "Civil works" as one head on a project that runs three years. Everything lands in it. The variance report says civil works is over budget, which you already knew, and cannot say whether it is labour, concrete, a rate revision or scope that was never in the budget at all. A head that cannot produce an action is a filing category, not a cost head.

A head so fine that nobody codes it consistently. The opposite failure, and it is commoner in offices that were burned by the first one. Sixty heads where twelve would do. The person coding cannot hold the distinctions in mind, so he picks by resemblance, and the fine structure fills with noise. Precision that is not achievable at the point of entry is not precision.

The same cost coded three ways. Shuttering hire booked to formwork by one person, to plant and machinery by another, to civil works by a third, each defensibly. Nobody is wrong. The structure permitted all three and never said which. Now no report on any of those three heads means anything, and the fault is invisible because every individual entry looks correct.

The structure moves under you#

A head invented mid-project. Something genuinely new arrives — a dewatering cost, an item of scope nobody foresaw — and a head is created for it. Sensible in itself. But the budget has no such line, so the comparison for that head is against zero, and the head it would otherwise have come out of shows an underspend it did not earn. Two lines are now wrong and only one of them looks it.

Renumbering. The quietest destruction available. Somebody reorganises the structure so it reads better. Every historical figure now sits under a code that means something else, and every comparison to last quarter is nonsense that still adds up correctly. This is the same disease that running account bills suffer when item codes change midway: the arithmetic survives, the meaning does not.

Coded to a project but not below it. Everything is tagged to the project. Nothing is tagged to a building, a tower, a wing or a floor. Then somebody asks what tower B cost — because tower B is sold to a different set of buyers, or funded by a different partner — and there is no answer that does not involve re-reading three years of invoices.

Contingency as a dumping ground. Contingency is meant for identified risk that may or may not occur. It becomes the head for anything that does not obviously belong elsewhere, because coding to contingency ends an argument. By the time it is exhausted nobody can say what it went on, which means nobody can say whether the project was over budget or merely mis-coded.

Overhead allocated with no stated basis. Head office cost is pushed onto projects by a method that lives in one person's spreadsheet. Change the method and the project's profitability changes without anything happening on site. If the basis is not written and not decided in advance, it will be questioned precisely when the number is inconvenient. Where several entities are involved the same problem sits one level up, in one builder, many companies.

What makes a structure survive#

It is decided by the person who will answer questions from it. Not by the accountant alone, and not by a software vendor's default chart. If the project head is the one who will be asked why tower B is over, he should be the one choosing the heads, because he is the only person who knows which questions get asked.

It is small enough to be remembered. The working test: can somebody coding an invoice list the plausible heads without opening a document? If he has to look it up, he will not, and he will use whichever head he remembers.

It separates what varies with quantity from what does not. Material and subcontract value move with what is built. Site establishment, supervision, plant on hire and finance do not, or move differently. Mixing them makes every per-unit figure a lie, and per-unit figures are what you carry into quoting a rate you can live with on the next job.

It never renumbers mid-project. Add a head if you must. Retire one if you must, and leave it in place, closed. Never reuse a code, for the same reason a bill of quantities keeps its item numbers to the end.

Coding happens once, at entry, by somebody who knows what the cost was for. Not later, by a person reading a description. The site engineer who raised the requirement knows what the material was for. The accounts assistant three weeks later knows only what the invoice says, and the invoice describes what the vendor sold, not what you used it on. This is also the moment when reconciling a vendor bill is cheapest, because the person who can answer the query is still nearby.

The short version#

A cost structure is designed for the budget and filled by the invoices, and that mismatch is the whole problem. Keep it coarse enough to code consistently and fine enough to answer the questions you actually get, including the ones below project level.

Fix the basis for allocations in advance, keep contingency for identified risk only, code at entry, and never renumber. A structure that survives a project is worth far more than one that was elegant at the start of it.

The collection ladder is written into the buyer's agreement: something on booking, something on agreement, something on each slab, something on possession. The payment ladder is written into the construction contracts: running account bills against measured work, advances against material, retention released at defined points.

The two ladders describe the same building. They are connected by physics — the slab that triggers a demand is the slab the contractor was paid to cast — and by nothing else. Different documents, different counterparties, different triggers, different timing.

The space between them, month by month, is what a developer's working capital actually is. Not a financing line. The arithmetic of two schedules that were never designed to meet.

Why they cannot line up#

Different measuring instruments. Buyers pay on a stage that somebody certifies as reached. Contractors bill on quantity that somebody measures. A stage is a discrete event; measured quantity is continuous. The contractor's bill for the month covers work spread across a stage boundary, and the buyer's demand covers a boundary the bill knows nothing about. The two documents describe the same concrete and cannot be reconciled line to line. That is normal, and worth saying out loud so nobody spends a month trying.

One event, many payers. A slab is cast once. It triggers a demand to every buyer in that tower, and each of them pays on his own schedule — some on the day, some after a reminder, some after a second reminder, some when their loan is disbursed, some not at all. One certain outflow has been matched against many uncertain inflows, and the distribution of those inflows decides whether the month is comfortable.

A defaulting buyer does not pause the contractor. The contractor's entitlement arises from work done. It does not care who has paid. Every collection problem on the sales side lands, unchanged in size, on the construction side, and the developer absorbs the whole of it.

Material is paid for before its stage is reached. Steel and cement for a slab are bought before the slab exists, sometimes months before, because rates were good or supply was tight or the contractor needed mobilisation. The money leaves on the material's schedule and returns on the stage's, and that gap is real cash. Whether the material has actually arrived when the money leaves is a separate discipline — money before material — and the gap is where a timing problem quietly becomes a loss.

Retention is money you hold that the buyer has already paid. You have deducted retention from the contractor. The buyer paid for the completed stage in full. So a balance sits with you which belongs to somebody, will be released later, and is not profit. It is the easiest money on a project to spend by mistake, because nothing about it looks restricted. The mechanics are in retention money; the point here is that any comparison of the two ladders which ignores it is flattering.

A stage completed just after a month-end. The slab is cast on the first of the month rather than the last of the previous one. Nothing has changed about the project. Everything has changed about the month — the demand goes out in the next cycle, collections land a month later, and the contractor's bill for the earlier month is already payable. Two ordinary days move a month's cash.

What to do about it#

You cannot make the ladders meet. You can stop treating them as one thing.

Model them as two schedules with a stated linkage. One schedule of expected collections by stage and by buyer. One of expected certifications and payments by contract. Then, written down, the linkage: which construction event triggers which demand stage, and by what definition. If that mapping lives only in the sales head's memory, the two ladders are connected by a person, and he will be on leave in the month it matters.

Publish the demand on the day the stage is certified. Not when somebody in accounts gets to it. The certification date is the earliest legitimate date; every day after it is financing you have donated, and the delay is almost always administrative rather than deliberate. Drafting the notice properly is its own subject — the demand letter — and is separate from the scheduling discipline of sending it on time.

Keep the deductions visible on both sides. Retention, advance recovery and set-off on the contractor side behave like part-payments and holds on the collection side: balances with a future, not reductions in value. Collapsing them into one net figure destroys the information, which is the argument running account bills make about certificates and which applies just as well to a collection statement.

Keep money and progress as separate facts. Cash collected is not work done, and work done is not revenue. Which is recognised when, and on what basis, is a matter for your auditor and the standards in force — verify that with them rather than from general reading. The operating point stands on its own: staged payments and accounting treat a stage as several distinct events, and a business that conflates them cannot tell a collection problem from a construction one.

Never report collections as progress. It is the most tempting number in a developer's office, because it is the easiest to produce and it moves. A good collection month against a bad construction month is a business getting worse and looking better. The reverse is a business getting better and looking worse. Report the two side by side, always, and never let either stand in for the other.

The short version#

Buyers pay on certified stages. Contractors are paid on measured quantity. The two ladders are joined by the building and by nothing in the paperwork, and the space between them is your working capital.

Model both as schedules, write down which construction event triggers which demand, raise the demand on the day of certification, and keep collections and progress as two numbers that are never allowed to substitute for one another.

That is the correct first move. The sheet costs nothing, needs no training, and is running before the hoarding goes up. Nobody should apologise for it.

It stops working for reasons that have nothing to do with discipline. The failures are mechanical. Naming them exactly is the useful exercise, because "we should move off Excel" is not an argument anybody acts on, while "the status on this row changed last week and nobody knows who changed it" is.

The failures, named#

One file, several people. There are only two arrangements and both are bad. Either the file lives on one laptop, in which case the sales team queues at one desk and the person who owns the laptop owns the truth. Or it is shared, and within a fortnight there are four copies with suffixes, each holding some updates the others do not, and no way to combine them except by reading both side by side.

No history. A lead moves from Hot to Cold. The cell now says Cold. It does not say who decided that, on what date, or after which conversation. The previous value is gone. Six weeks later the manager asks why a good enquiry was dropped, and the honest answer is that the sheet cannot tell anyone.

A sort that took the range and not the row. Somebody selects the status column, sorts it, and the statuses reorder while the names and numbers stay put. Every row in the file is now wrong, quietly and permanently. There is no error message and no undo an hour later.

A filter left on. The last person filtered to one project and closed the file. The next person opens it and sees a subset which looks like the whole. Leads that exist, that were paid for, are invisible to the person whose job is to call them.

The lead entered at the bottom, or not at all. A sheet is unusable on a phone. So the caller at a hoarding or a mall kiosk writes the number on paper, or sends it to their own WhatsApp, and enters it in the evening. Some evenings that does not happen. The enquiry the marketing budget bought never reaches the file.

The same buyer entered twice. Two callers, two rows, two owners, and one irritated buyer receiving the same pitch twice. A sheet has no way to warn anybody, and the duplicate is usually found at booking, which is the worst possible moment. The mechanics of that case are their own subject — one buyer, three enquiries.

A date in a cell does not ring. This is the one that costs the most money. The sheet can hold follow up on the fourteenth perfectly well. It simply never mentions it again. The date is a fact, not an instruction, and a fact sitting in a cell has never called anybody.

The month-end rewrite. Before the review, the sheet is tidied. Stale rows are deleted, statuses are moved to match what was reported, the count is made to agree with the count that was announced. The file that survives is a report, not a record, and the following month starts from it.

Why the sheet survives anyway#

Because it is genuinely good at three things, and anyone proposing a replacement is competing with all three at once.

• It is instantly editable. A new column costs three seconds and no permission. When a new tower launches and somebody wants to track floor preference, it is tracked that afternoon.
• Everybody can read it. No training, no login, no explanation. A manager who has never seen the file can understand it in a minute.
• It costs nothing and asks nobody. No approval, no procurement, no vendor.

Any replacement is measured against these three whether or not the person comparing says so out loud. A system where adding a field means raising a request and waiting a week will lose to the sheet, no matter what else it does, because the sheet will reappear on somebody's desktop the first time the system says no. This is one of the places where the shipped defaults are decisions — what the software makes easy on day one is what the office will actually do.

What a sheet structurally cannot do#

Three things. Not does badly — cannot, because of what a spreadsheet is.

Hold history. A cell holds one value: the current one. Every change is a destruction of the previous state. A sales record needs the opposite property, where new information is added and nothing is overwritten, which is the whole argument for append-only records.

Be read and written by two people at once. Not "shared" — genuinely concurrent, with both people's work surviving. Two callers working the same list at the same hour is the ordinary case in a sales office, not an edge case.

Act on a date by itself. A record that knows a follow-up was due yesterday and says so, unprompted, to the person who owes it. Everything a sales team does is a sequence of dated promises, and a system that cannot act on a date is just a filing cabinet with better arithmetic. What that looks like when built properly is follow-up as a schedule.

Those three are the entire brief. A lead system that holds history, takes two people at once, and acts on dates by itself has earned its place. One that does those three and is also slower to edit than a sheet has still won, because the three are not conveniences.

Before you replace it#

Take last quarter's sheet and try to answer three questions from it alone. Who changed this lead's status, and when? Which follow-ups were due last week and not made? Which of these rows are the same person?

If the file cannot answer them, that is not a failure of the person who kept it. It is a description of what the tool is. The next tool should be chosen by whether it answers those three, and by whether the caller standing at a kiosk can enter a name into it in ten seconds. Both, or neither will be used. The field-by-field version of that requirement is what a lead record should hold.

The short version#

The sales sheet is not a bad decision, it is a tool with three structural limits: no history, no concurrency, and no ability to act on a date.

It survives because it is instant, readable and free, and any replacement must match all three or it will be quietly abandoned.

Judge the replacement by whether it can say who changed a status and when, which follow-ups are overdue, and which rows are the same buyer.

The rate is agreed early, in writing, usually in one line, and both sides remember it. Almost nothing is ever disputed about the rate.

The fights are about two other things. Who brought this buyer. And when, exactly, does the money become payable. Both are questions the arrangement should have answered before the season started, and usually did not.

Where attribution breaks#

Two brokers claim the same buyer. The commonest case and the hardest. One sent the enquiry on WhatsApp a month ago; the other walked the buyer into the site office on Sunday. Both are telling the truth about what they did. Without a rule decided in advance, this becomes a negotiation between two firms you need next quarter, settled by whoever argues harder.

The buyer comes back direct. A broker showed him the project. He went away, thought about it, and returned on his own — or through the portal, or through your own tele-caller ringing an old enquiry. The broker's work is real and invisible. Your team's work is real and documented. Nothing about the record resolves this on its own, and if the two approaches were captured as two separate rows you have a duplicate to untangle as well as a claim to settle, which is one buyer, three enquiries.

A tagging window nobody wrote down. Most offices operate some version of "a registered client stays with that broker for a while". How long is a while varies by whoever is asked, and is discovered only when it matters.

The junior who is not the firm. A large channel partner's associate brings the client. He is not the empanelled firm, or he has moved to another firm since, or he works with two. The payout is due to a name on an agreement; the work was done by a person; and the person expects to be paid.

The record was made after the fact. The registration is emailed on Monday for a client shown on Saturday, or entered by your own executive from memory at month end. An attribution record written after the outcome is known is not evidence of anything, which is why the date on it has to be the date it was created and not a date somebody typed. The same discipline that makes any record trustworthy applies here — append-only records exist for precisely this class of dispute.

Underneath all of these is the same question your own team argues about internally, which is who owns the lead. A broker claim is an ownership claim from outside the payroll, and an office that has not settled ownership internally will not settle it with an outsider.

Where timing breaks#

The booking cancels after the payout is made. Money has left. Now it must come back from a firm that has already distributed it to the person who did the work. Recovery of a paid brokerage is one of the least pleasant conversations in the business, and it is entirely avoidable by paying later.

The payout is tied to a milestone the broker cannot see. Registration done, or a stage payment received, or agreement executed. All reasonable triggers. But the broker has no way to know whether the trigger has occurred, so he rings the sales manager, who rings the CRM desk, who checks. Three people's time, per call, per broker, for a fact that already exists in your records.

"It is in process." The broker asks. Nobody wants to say a number, so he is told it is in process. He is told the same thing the next time. What was a payment question becomes a trust question, and the next enquiry he generates goes to a competitor who pays predictably rather than generously.

A short payment with no reason attached. A deduction is made — for a discount he agreed to, for tax withheld, for an earlier cancellation — and the remittance carries no explanation. The broker sees only that less arrived than was promised, which is exactly the situation described in paying less than agreed: the deduction may be entirely correct, and it still reads as a broken promise unless it says why.

What a workable arrangement contains#

Four things, all decided before the launch rather than during the first argument.

• A written attribution rule. Not a principle — a rule with an order of precedence, covering the direct-return case and the two-claim case explicitly. It will be unfair to somebody in some case. A rule that is known in advance and slightly unfair beats a fair decision made after the fact.
• A dated registration with an expiry. The client is registered to the broker on a date, and that claim lapses on a date. Both dates visible to both sides. An expiry is what stops a broker registering the whole city and waiting.
• One visible status. A single line per case that can be read out or sent without anybody investigating: registered, visited, booked, agreement done, payout due on the next receipt. The purpose is to end the ringing.
• A payout schedule tied to money received. Not to booking. Brokerage released in step with the buyer's own instalments behaves like every other staged obligation in the business, and the reasoning is the same as in staged payments and accounting — the promise is made once, the money moves in parts, and the record has to hold both.

One office habit worth more than the rules#

The person who confirms attribution should not be the person whose target it counts against.

A sales manager deciding whether a walk-in "really" came through a broker is deciding whether the sale counts as his team's or as channel. He may be scrupulous. He is still being asked to rule on his own number, every time, at speed, in front of the broker.

Move that decision one desk away — to CRM, to the person who does post-booking paperwork, to anyone whose incentive does not move with the answer. The rule you wrote is only as good as the independence of whoever applies it, and this costs nothing to arrange on day one and is nearly impossible to introduce later without it looking like an accusation.

The short version#

Channel partner disputes are about attribution and timing, not rate.

Decide the attribution rule in writing before the season, register clients with a date and an expiry, and let the broker read one status without ringing anybody.

Pay against money actually received rather than against booking, explain every deduction on the remittance, and put the attribution decision with somebody whose own number does not depend on the answer.

The arguments never resolve, because they are being had in the wrong terms — as a debate about what would be nice to know rather than about what will be filled in and acted upon.

There is a single test that settles them. For any proposed field: who reads it, and what do they do differently because of it? If neither half has an answer, the field is decoration, and decoration is not free — it makes the form longer, which makes capture slower, which means fewer enquiries get captured at all.

Identity: the fields that let you find the duplicate later#

The point of the identity fields is not to address the buyer politely. It is so that when the same person appears again through another channel, the system can recognise him.

The phone number is the spine. It is the only field in this market that is close to unique, close to stable, and always given. It should be stored in one normalised form — country code handled the same way every time, no spaces, no hyphens, no brackets — because a number stored two ways is two people as far as any comparison is concerned.

The name is a weak key. The same buyer appears as a full name on one record, an initial and a surname on the second, the same name with ji attached on the third, and a spelling the caller heard over a bad line on the fourth. Regional spellings vary and initials expand and contract. Keep the name, display it, never match on it alone.

Email is weaker still. Many buyers give none, or give one they never read, or give the family address that already sits on the son's enquiry. Store it. Do not build anything on it.

Alternate numbers deserve their own place, not a note in a remarks box. The spouse's number, the son's number, the office landline. These are the numbers that later cause a "new" enquiry that is not new — the whole mechanism is in one buyer, three enquiries.

Source, recorded once and never overwritten#

Source is where this enquiry came from: which portal, which hoarding number, which campaign, which broker, which walk-in.

The rule that makes it worth anything is that it is written at capture and never changed by a later touch. If the buyer later fills a form on the website, the record should gain a second touch — not replace its original source with the website. Every marketing decision you make afterwards depends on that first value being the truth about where the enquiry originated.

Systems get this wrong by design more often than by accident: last-touch overwriting is the easy thing to build, and it makes whichever channel calls last look like the channel that works. What the software does by default is what the numbers will say a year later, which is the argument in defaults are decisions.

Requirement and budget#

Requirement, in the words the buyer used. Two BHK, park facing, ground floor because the mother cannot climb stairs. A dropdown with 2BHK / 3BHK flattens that into a category and destroys the part that closes the sale. Keep a structured configuration field for counting, and keep the buyer's own sentence beside it. Both. They do different jobs.

Budget as a range, with the date it was said. Nobody has one number, and whatever was said in March is not what is true in September after he has seen four other projects. A budget with no date attached is treated as current forever, and the caller works from a figure that expired months ago.

Neither field should be mandatory at capture. A tele-caller with a moment of a stranger's attention gets a name, a number and a project. Requiring the budget before the record can be saved does not produce budgets — it produces records that never get saved, or a column of the same placeholder figure.

Stage, next action, history#

These three carry the whole system.

Stage, defined in words. Not a colour, not Hot / Warm / Cold. Each stage needs a written definition that two different people would apply identically: what has happened for a lead to be in it, and what must happen for it to leave. "Warm" means whatever the person typing it felt that afternoon. "Visit done, objection not yet answered" means something a manager can act on.

The next action, with a date and an owner. This is the most valuable field on the record and the one most often empty. Three parts, all required: what will be done, on what date, by which named person. Not a team, a person. A next action with no date is a wish, and a date with no owner belongs to nobody. The reason to insist on all three is that this is the only field a system can act on by itself, which is the subject of follow-up as a schedule.

History, which is every previous next action and what came of it. Not a remarks box that people append to until it is unreadable. Each completed action keeps its date, its owner, what was promised and what actually happened. This is what makes the record readable by somebody who has never spoken to the buyer — the manager on Monday, the replacement when the executive leaves, the CRM desk after booking.

What not to put in#

Fields nobody will fill. Every optional field that stays empty teaches the team that empty is acceptable, and that lesson spreads to the fields that matter.

A score computed from fields nobody filled. A rating out of a hundred derived from budget, timeline and profession, where two of the three are blank for most records, is arithmetic performed on absence. It looks authoritative on a dashboard and it is noise. Worse, people will start working the score instead of the record.

Free text where a date belongs. "Will call next week" in a remarks column cannot be sorted, cannot be counted and cannot ring. This is the single habit that carries the spreadsheet's central weakness into the new system — leads that die in an Excel sheet is mostly a description of that one failure repeated in different forms.

Anything copied from another record. The project's price list does not belong on the lead; copies go stale and callers quote them.

The short version#

The identity fields exist to catch the duplicate, so the phone number is the spine and everything else is a weak key.

Source is written at capture and never overwritten. Requirement keeps the buyer's own words alongside the structured value. Budget is a range with a date.

Stage needs a written definition, the next action needs a date and a named owner, and the history needs to hold every previous one. And for each new field somebody proposes: who reads it, and what changes because of it.

Every other question about a sales process — follow-up discipline, conversion counting, why a good enquiry went cold — resolves back to this one. If you cannot name the single person responsible for an enquiry at any given moment, nothing downstream of it can be measured or corrected.

The rules that have to exist before they are needed#

There are five, and each one will be argued about eventually. The only real choice is whether they are decided in advance and written down, or invented during the argument, in front of the people affected.

• How a new enquiry is assigned. Round robin across the team, by source, by project, by the language the buyer speaks, or by who is on shift. All of these are defensible. Round robin is the fairest and ignores fit. Assignment by language or by project is better for the buyer and produces uneven workloads that then need managing. Pick one, say why, and write it down.
• What happens when the owner is on leave. Enquiries do not pause for chhutti. Either the lead moves and comes back, or a cover person acts on it while ownership stays put. Both work. What does not work is nothing, which is what happens by default, and the buyer who called on a Tuesday hears from nobody until the following week.
• When ownership lapses. If nothing has been done on an enquiry for a defined period, it should return to the pool and become available. Without this rule, ownership is permanent and hoarding is free.
• What happens to a lead that returns after a year. The old owner may have left, changed projects or forgotten the buyer entirely. Is it a new enquiry or a revival of the old one? This must be decided once. The record should keep both histories either way.
• Who decides a transfer. Not the two people involved. A named role, with the decision recorded. Transfers agreed privately between executives are the ones that produce a claim at booking, from a third person who was never told.

Why this is not an administrative matter#

Ownership is compensation. That is the whole reason these questions are hard.

A rule that moves a lead moves money, from a named person to another named person, in an office where everyone knows both. This is why arguments about assignment are more heated than arguments about anything else in a sales office, and why they cannot be settled by whoever is senior in the room on the day.

It also means the rules must be published before the first dispute rather than after. A lapse rule introduced the week after a large booking looks like a decision about that booking, whatever the intention. The same rule announced at launch, when nobody knows who it will affect, is just a rule. This is one specific case of the general principle in who is allowed to decide: the authority for a decision has to be settled before the decision is contentious.

The failure modes#

Assigned to a team. The enquiry sits with "the Sunday team" or "site office". Every member sees it, each assumes another has called, none has. This is the ordinary way work dies between people, and the mechanism is exactly the one described in why tasks stall between people — responsibility that is shared is responsibility that is unheld.

Two owners. Usually the result of a transfer done in one place and not the other, or of a duplicate record. The buyer receives two calls with two versions of the price, and finds out that the office does not talk to itself.

An owner who has left. Nobody removes departed staff from assignments, and a portion of the pipeline is now assigned to a person who does not come to work. These leads receive no calls and appear in no queue, because a queue is usually built per active user.

Silent reassignment. The manager moves a lead without telling the previous owner. He finds out when the booking is announced. Whatever the merits of the move, the cost is paid in trust and collected for years.

Hoarding. An executive holds a stack of enquiries he has not called in weeks, because holding them costs nothing and releasing them means somebody else might convert one. This is the direct consequence of no lapse rule, and it is a rational response to the incentives, not a character defect.

Making a lapse rule that people accept#

A lapse rule is the one that decides whether the whole arrangement is seen as fair, because it is the one that takes something away. Three properties make the difference.

A visible countdown. The owner can see, on the record, how long he has before it lapses. Not a policy in a circular — a number on the screen he is already looking at. A lapse somebody can see coming is usually a lapse that does not happen.

A warning before the event, to the owner and to nobody else. A private nudge first. If the lapse rule's first announcement is public, it functions as a reprimand, and people will start making a token call on every stale lead to reset the clock. What you get then is worse than hoarding: activity performed for the counter. Warnings work when they are early, quiet and addressed to the person who can still act, which is the design argument in escalation without shame.

A record of who took it, and when. When a lapsed lead is picked up, the transfer is written with a date and a name. If that lead books, the history shows exactly when ownership changed and under which rule, and the commission conversation is a reading exercise instead of an argument.

None of this works unless something in the system is actually watching dates and acting on them without being asked, which is the machinery described in follow-up as a schedule. A lapse rule enforced by a manager remembering to check is not a rule.

The same questions arrive from outside the payroll when a channel partner claims a buyer. The vocabulary changes and the structure does not — working with brokers is the external half of this problem.

The short version#

Name one person per enquiry, always. A lead owned by a team is owned by nobody.

Decide assignment, leave cover, lapse, revival and transfer authority in writing before the first dispute, because after it any rule looks like a verdict.

Make lapses visible in advance, warn privately, and record every change of owner with a date and a name.

Three records. Three owners. Three people who will ring him this week with the same pitch, and at least two of whom will believe they are talking to a fresh enquiry.

The buyer's experience of your organisation is now settled, and it is that the left hand does not know what the right is doing. If he books, there is a commission argument waiting. If he does not, three executives will each report a lost lead, and your enquiry count for the month is wrong by two.

Why exact matching fails in this market#

Every system ships with duplicate detection that compares two phone numbers for equality. It catches almost nothing, for reasons that are entirely ordinary.

The country code. The portal delivers the number with a code prefixed. The tele-caller types the ten digits she was told. The broker's registration email has it written a third way. Three strings, one phone.

Spaces, hyphens and brackets. A number typed with a space in the middle, or split with a hyphen because that is how the buyer said it, is a different string to a computer and the same number to a person.

The spouse's number. He enquires on his own number and his wife walks in and gives hers. Both are correct contact numbers for one household and one purchase decision.

Two spellings of one name. Transliteration from a regional script varies, initials expand or contract, and the caller writes what she heard through a call that was breaking up.

A shared family email address. One address serves the father, the son and the business. Matching on it will merge people who are genuinely different, which is a worse error than missing a duplicate.

The portal's proxy number. Some sources deliver a masked line that routes to the buyer rather than his actual number. Two enquiries from the same person through two portals arrive as two different numbers, neither of which is his.

Notice that half of these are cases where naive matching finds nothing, and half are cases where it would confidently merge two people who are not the same. Both errors are expensive and the second is harder to undo.

What a duplicate rule should do#

Normalise before comparing. Strip everything that is not a digit, handle the country code the same way on every path in, and store one canonical form. This has to happen at the point of capture and on every route — portal feed, bulk import, walk-in form, the app the caller uses at a kiosk. A normaliser applied on three routes out of four produces duplicates that look impossible.

Treat the phone as the spine and everything else as a hint. A matching number is strong evidence. A matching name is a reason to look. A matching email is barely anything. That ordering is the practical half of what a lead record should hold, and it is why alternate numbers deserve a real field rather than a line in a remarks box — they are the ones that catch the household case.

Propose a merge; do not perform one. This is the important one. The system should say this enquiry looks like that one, here are both, decide — and then wait for a person. Automatic merging on a fuzzy match will eventually combine two genuine buyers, and the damage is silent: one buyer stops receiving calls, one history becomes nonsense, and nobody finds out until somebody looks for a record that no longer exists under its own name. The general form of this rule is the machine proposes, and duplicate detection is the case where it earns its keep most obviously.

Never destroy the losing record's history. A merge should join two histories, not overwrite one with the other. The dates, the owners, the notes and the source of the second enquiry all survive.

The second enquiry is information#

This is the part most implementations miss. A duplicate is treated as a mistake to be cleaned up, and cleaning it up destroys the fact.

That the same man enquired three times in one week, through three channels, is the strongest intent signal in the file. It is worth more than any rating out of five. A merged record that shows three touches in six days, from three sources, tells the executive exactly how to open the call.

There is also a marketing fact in there. The portal, the hoarding and the broker each produced an enquiry from this buyer. If the merge overwrites source with the most recent one, the hoarding and the portal have both silently lost credit for a booking they helped produce, and next season's budget is set from that damaged number. Keep every touch with its own date and source, and let the current values sit on top of a history that is added to rather than rewritten — append-only records is the same discipline applied to a different desk.

A merge is an ownership decision#

Two records had two owners. One merged record has one. Somebody's name has been removed from a live enquiry, and if that enquiry books, somebody's earnings changed while a screen was being tidied.

This means a merge cannot be a housekeeping task handed to whoever has time on a Friday. It needs the same authority a reassignment needs, the same written rule about which owner prevails — first touch, most recent activity, the one who has actually met the buyer — and the same record of who decided and when. All of that is who owns the lead, and a duplicate policy written without settling it will be quietly ignored by the executives it costs.

There is a related trap. If the office knows that merging removes an owner, duplicates stop being reported. Everyone can see the second record and nobody raises it, because raising it might cost a colleague a case, or cost them one. A merge rule that names the losing owner and pays nothing to the finder is a rule that guarantees nobody looks.

The short version#

The same buyer arrives through several channels in the same week, and exact matching on a phone number will not catch it.

Normalise numbers at every point of capture, treat the phone as the spine and the name and email as hints, and propose merges for a person to confirm rather than performing them automatically.

Keep both histories, keep every source and date, and treat the merge itself as a change of ownership requiring the same authority and the same record as any other.

That single fact reorganises the whole pipeline. Every stage before the visit exists for one purpose, which is to produce a visit. Every stage after it depends entirely on what happened while the buyer was there, and on how much of that survived the drive home.

Most sales reviews spend their time on the counts at either end of the funnel. The visit sits in the middle, it is the most expensive event for both sides, and it is usually the worst recorded.

Where visits are lost#

Scheduled and never confirmed. A visit fixed on Tuesday for Sunday, and nobody rings on Saturday evening. Some fraction of those people simply do not come, and the executive discovers it by waiting.

The person who knows him is elsewhere. The buyer arrives and the executive who has spoken to him four times is on another visit, on leave, or at lunch. Whoever is free receives him, knows nothing about him, and starts again from the brochure. The buyer has to explain his own requirement to a stranger, which is the moment much of the goodwill built over four calls is spent.

The sample flat is locked. Or the lift is not working, or the security staff have no instruction and the family waits at the gate, or the site is a mess because a pour is on. Each of these is somebody's ordinary day and all of them are the buyer's only impression.

Nobody records the objection. He came, he liked the layout, he thought the carpet area was tight for the price and he did not like the distance from the main road. Nobody writes that down. The follow-up call two days later is the same pitch he has already rejected, delivered with enthusiasm, and it confirms to him that nobody was listening.

The notes live in one person's phone. Written on WhatsApp, or in the executive's own notebook, or in his head. The manager cannot see them, the CRM desk cannot see them, and when the executive leaves the company the buyer's entire history leaves with him. That is the failure described in filed as chatter — real work recorded somewhere that is not the record.

The second visit with the family. He returns with his wife, his father and the brother-in-law who has opinions. Nobody prepared for it, so the decision makers who actually matter are met cold, in a group, without anybody knowing who among them needs convincing of what.

The gap between visited and first follow-up. A visit ends, and the next contact happens some days later, when the executive gets around to the list. The buyer has seen two other projects in that time. Whatever heat the visit produced was allowed to cool because nothing insisted on a date, which is what follow-up as a schedule exists to fix.

The five things to capture#

Not a form with twenty fields. Five, and each one has to earn its place by changing what somebody does next.

• Who actually came. Not who was invited. The names and relationships of everybody who walked the site, because the person who asks the most questions is often not the person whose name is on the enquiry. This is the field that tells you who to invite for the second visit and whose objection is the one that matters.
• What they asked about. Questions are the shape of interest. Somebody asking about the possession timeline, the loan tie-up, or the school on the next road is telling you what he is actually deciding between.
• What they objected to. The most valuable of the five and the one most often left blank, because writing down an objection feels like admitting the visit went badly. It did not. An objection is the only thing the next conversation can usefully address.
• What was promised. A discount hinted at, a floor held, a payment plan suggested, a car park thrown in. Promises made at a site office have a way of becoming disputes at booking, and the person who made one is not always the person who has to honour it.
• The next action, with a date and a name. Same rule as everywhere else in the record: what, when, by whom. Without it the other four are notes, and notes do not ring.

Everything else is optional. If a proposed sixth field cannot say who reads it and what changes because of it, leave it out. A longer form at the gate produces shorter answers, and the case for keeping the set small is made in what a lead record should hold.

Capture it before he leaves#

This is a discipline, not a feature, and it is the difference between the five fields being worth something and being worth nothing.

Written at the site, while the family is still walking back to the car, the notes contain what was actually said. Written that evening, after two more visits, they contain a summary of an impression. Written the next morning, under a manager's eye, they contain what the executive thinks the manager wants to read.

The obstacle is real: the executive's hands are full and he is being polite to a family. Which is why the capture has to survive being done badly. A voice note recorded in the car park, in whatever language the executive actually thinks in, is a better record than a form filled in perfectly six hours later — the voice note is the report makes that case for the site side of the business, and it holds just as well at the sales office.

The same argument applies to the photograph. A picture of the flat the family stood in, taken during the visit and attached to the record, keeps its own date and its own subject, which is what makes a site photograph a record rather than a picture. It answers the question everybody asks at the second visit: which one did we show them?

What to look at on Monday#

Two questions, asked of last week's visits.

For how many is there a written objection? If it is a small share, the office is not recording the one thing that decides the sale.

And how many days passed between the visit and the first contact after it? Not the average — the worst one. That number is the honest measure of whether the most expensive event in your funnel is being followed up or filed.

The short version#

Nothing sells without a visit, so the visit is the only stage where the pipeline is really decided.

Capture five things before the buyer leaves the site: who came, what they asked, what they objected to, what was promised, and the next action with a date and a name.

Notes taken in the car park beat notes written that evening, and an objection nobody wrote down guarantees a wasted follow-up call.

Intention is not a schedule. A schedule is a dated commitment that surfaces on the correct day whether or not anybody remembers it. Everything else is a feeling about a buyer, and a feeling does not appear on Monday morning's list.

Leads do not go cold, they go quiet#

"Cold" is a comfortable word because it puts the fault on the buyer. He lost interest. He was never serious. He was only comparing.

Sometimes that is true. More often what happened was a gap. The buyer walked the site, went home, and heard nothing for a week and a half. In that silence he spoke to two other people, and one of them rang back within a couple of days with the floor plan he had asked about.

Nothing was decided against you. You were simply absent during the only period in which he was actively thinking about it. By the time your call came, his question had already moved from which project to which bank.

This is why follow-up discipline pays better than any change to the pitch. The pitch competes on quality. The schedule competes on presence, and presence is the cheaper of the two to fix.

Two endings, and no third#

Every conversation with a prospective buyer must finish in one of two states.

• A next action with a date. One name, one sentence saying what will happen, and the day it happens on. "Send revised cost sheet with the corner unit — Thursday." Not "follow up soon".
• Closed, with a reason. He booked elsewhere. His budget is half of ours. He is not buying for two years. The unit he wanted is already sold.

Anything else is a lead in limbo, and limbo is where a pipeline turns into a number nobody trusts. A record with no next date and no closing reason is not being worked. It is being stored.

The reason matters as much as the date. A team that cannot close a lead without an argument will never close one, and the list grows until it is decorative. Make spoke, not interested a single, blameless action. The manager's job is to read those reasons, not to punish them.

Where the schedule breaks#

The method is trivial. The failures are specific, and most sales offices are running several of them at once.

"Will call next week." No day, so no list can carry it. Next week arrives and the item is invisible, because the only place it ever existed was the end of a sentence.

The reminder that fires at the wrong moment. It rings while the caller is on another call. He dismisses it to stop the noise. The dismissal is permanent and the record now reads as handled. An alert that can be silenced without recording an outcome is worse than no alert, and the whole failure class is an alert that rings for everything.

An overdue list longer than the working day. When the pending list is bigger than anyone can finish, it stops being a set of obligations and becomes wallpaper. A couple of overdue items get attention; a screen full of them gets scrolled past. The overdue count is the health measure of the whole system, and letting it grow without limit kills the system quietly.

Follow-ups timed for when the buyer is at work. Everything lands at ten in the morning because that is when the caller starts his day. Half the buyers are in meetings, the other half are driving. The item is attempted, unanswered and marked done. The record says contacted. Nobody was contacted.

The eternal reschedule. The same item is pushed forward week after week with no new information between pushes. Each push feels like diligence. Together they are a decision nobody is willing to make — the lead is dead and no one wants to write that down. An item rescheduled many times without a conversation should look different on the screen from one due tomorrow.

The shared spreadsheet. It has no notion of a date arriving, no notion of whose item this is, and no memory of what was promised. It is the most common follow-up system in the industry, and its particular failures are set out in leads that die in Excel.

What a working list looks like#

Small. That is the first property, and it decides all the others.

A caller opens his day and sees a handful of items due today, each carrying one line of context: who, what was last said, what was promised. If he has to open the record to remember the conversation, he will not open it. He will ring and improvise, and the buyer will hear it.

Every item needs a visible reason. "Call the customer" is an instruction. "Call — promised the revised cost sheet after he asked about the corner unit" is a conversation the buyer recognises from the first sentence. What the record itself has to carry for that to be possible is in what a lead record should hold.

And closing must be as easy as scheduling. If marking a lead dead means a long form and a dropdown nobody understands, the list only ever grows. Shrinking it is the healthy behaviour, so make it the cheapest action on the screen.

The ledger of what was not sent#

We built two things around this, and the second one surprised us.

The first was a ceiling. Every message has a home — a quiet feed, a daily bulletin, a knock, or the one tone that interrupts — and its home can only ever make a message quieter, never louder. Nothing promotes itself.

The second was a ledger recording who was told what and why, including the occasions when nothing was sent. That last entry is the one that earns its keep. When somebody says they were never informed, the useful record is not the list of messages that went out. It is the reasoned line explaining why one did not.

The manager reads reasons, not counts#

The weekly review in most offices is a count. Calls made, site visits done, bookings closed. Counts are easy to produce and easy to inflate — an unanswered call is still a call.

The useful review reads the closing reasons instead. A run of leads closed as budget too low is a pricing or a targeting problem, not a sales problem. A run closed as unit not available means the inventory the team is being asked to sell is not the inventory buyers are coming for. A run closed as no response usually means the first call went out too late.

None of that shows up in a count. All of it shows up in the reasons, and only if the reasons are cheap to record and honestly written.

The same principle governs work inside the office as governs buyers outside it. An obligation with a date can be watched, and something drifting can be seen before the deadline rather than after, which is the argument in work slips before it is late.

The short version#

A follow-up that lives in somebody's memory is not a follow-up. Every conversation ends with a dated next action or a closing reason, and there is no third ending.

Keep the due list small enough to finish, give each item a reason the buyer would recognise, and make closing a lead as easy as postponing one. Then read the reasons at month end — the count will tell you the team was busy, and the reasons will tell you what to change.

What follows is the structure of that sequence. The legal requirements — what must be registered, what stamp duty applies, what disclosures are mandatory, what timelines bind you — differ by state and change. Take the structure from here and verify the version in force with your own advisor.

The rungs, in order#

The sales side, before the file becomes a legal instrument:

1. Expression of interest or application. The buyer states which unit, on what terms, and signs something. This is the first document with his handwriting on it and it is routinely treated as a formality.
2. The booking amount and its receipt. Money moves. A receipt goes back naming the unit, the amount, the mode and the date. Not a WhatsApp acknowledgement.
3. Allotment. Your side confirms the specific unit against that application. Until this exists, the buyer has paid for an intention.
4. The cost sheet. Every component of what he will pay, in writing.
5. KYC of every applicant. Identity and address for each name that will appear on the agreement, not just the one who came to the office.

Then the legal side:

1. The agreement draft, prepared from the allotment and the cost sheet.
2. The buyer's review, which is a real step with a real duration and often a lawyer at the other end.
3. Execution and registration, whose formalities are governed by law in force where the project sits.
4. The loan file, running in parallel the whole time, on its own schedule, asking for copies of everything above.

The loan file is the one people forget when they design a process. It is not a step at the end. It starts early and it audits your paperwork on the bank's timetable rather than yours.

What the cost sheet has to state#

The cost sheet is the document most disputes come back to, because it is the only place where the whole price is assembled in one view.

It should state the base consideration and how it was derived, every additional charge by name, the taxes as separate lines rather than folded into a total, the payment plan with its stages, what is included in the unit and what is not, and what is not yet quantified. A charge that appears for the first time in a demand letter three years later, and was never on the cost sheet, is an argument you will lose in the room even if you win it on paper.

Date every version. Cost sheets are revised during negotiation, and each revision creates a document that looks exactly like the one it replaced.

Where the ladder breaks#

The cost sheet that differs from what was said. The executive promised free covered parking and the sheet charges for it. The buyer signed the sheet, so you are legally comfortable and commercially finished, because he will remember the conversation for as long as he owns the flat.

A second applicant added after allotment. A wife, a father, a son added later. Now KYC is incomplete, the allotment names one person and the agreement names two, and the bank asks which is correct.

The unit sold twice. Blocked in the sales sheet by one executive and sold from the sample flat by another over a weekend. Inventory that lives in two places is inventory that will be sold twice, and the cost of unwinding it is paid entirely by you.

KYC collected as photographs on a phone. A gallery of blurred documents in somebody's personal handset, some of which no longer exist because he changed his phone. Nobody can say which photograph belongs to which applicant.

The document the bank asks for that nobody kept. The receipt for a payment made in the first month, the earlier version of the cost sheet, the signed application. Disbursement stops for a document you had and did not file.

A draft signed after it was superseded. Two versions in circulation, one by email and one printed at the site office. The buyer signs the older one because it was the copy in front of him.

The long gap with no owner. Months pass between booking and agreement. The executive who sold it moves on, no one inherits the file, and the buyer rings a number that has been reassigned. That entire period, and how to staff it, is after the booking comes the longer job.

The sales record and the legal file are different things#

The sales record is the office's working memory: who this buyer is, what he was quoted, what is pending, who spoke to him last. It is edited constantly and that is correct.

The legal file is the set of documents that will be produced if anything is ever contested. It is not edited. Each item enters it once, in a fixed form, with the date it was signed and by whom.

Most offices keep one folder and treat it as both, which means the file that would be produced in a dispute has been edited by whoever needed to correct a phone number. Keeping them separate costs nothing but discipline, and the reasoning behind an unedited record is set out in what an audit trail is for.

A related point about scans. A scanned copy is not the record unless somebody can prove which copy it is. Two PDFs of the same page, one signed and one not, are indistinguishable in a folder listing. Either the file itself carries evidence of what it is and when it was made, in the sense described in tamper-evident documents, or your archive is a collection of pictures.

Tell the buyer plainly to keep his own set as well — the receipt, the cost sheet he signed, the allotment, every payment acknowledgement. That habit is keep your own copy, and a buyer with his own file is easier to deal with, not harder.

The one habit worth installing#

A document checklist per unit, with a state per item, that the sales desk and the CRM desk both read from the same screen.

Not a checklist per project and not a checklist in somebody's diary. Per unit, because the unit is the thing that gets sold, financed, registered and handed over. Each item has a state — not required, pending with buyer, received, verified, filed — and a name against it.

When the bank rings, the answer takes seconds. When the executive leaves, his replacement opens the same screen.

The short version#

Between yes and registration sits a fixed sequence of documents, and the sale is only as sound as the weakest rung.

Get the cost sheet complete and dated, collect KYC for every applicant before allotment, keep sales working notes separate from the legal file, and run one per-unit checklist that both desks read. Then verify the legal specifics for your state with your own advisor, because that part is not the same everywhere and it does not stay still.

That sentence hides the entire collections function of a builder's office, and almost every dispute in it is not about whether the buyer owes the money. It is about whether the demand was properly raised, stated and received.

What follows is the structure. Interest on delay, permitted charges, notice periods and what a regulator requires you to state are set by law and vary by state and by project. Verify the version in force with your own advisor.

What actually triggers a demand#

Three things have to be true before a demand letter should leave your office.

• A stage has completed. Not nearly completed. Not completed on the plan.
• Somebody has certified it. A named person, on a named date, whose certification exists as a document rather than as a conversation in a meeting.
• The trigger matches the buyer's agreement. The stage names in the payment schedule must be the stage names the site uses, or somebody is translating, and translation is where the argument starts.

That third one is the quiet failure. The agreement says "on completion of the slab of the floor on which the said unit is situated". The site talks about the slab it poured last week. Whether those are the same event for a given unit is a question somebody must answer, and if the answer lives in one person's head it leaves when he does.

What the demand must state#

A demand that will not be disputed later says all of this on its face:

1. The unit, unambiguously — tower, floor, number, and the buyer's name as it appears on the allotment.
2. The stage that triggered it, in the same words the agreement uses.
3. The certification — who certified the stage complete, and when.
4. The amount, broken into components rather than one figure: the instalment on the base consideration, each additional charge, and taxes separately.
5. What was already paid, cumulatively, so the buyer can place this demand in the story of his own account.
6. The due date, and how to pay — the account, the reference to quote.

Number five is the one most offices skip, and the one that reduces disputes most. A buyer who can see his running account reconciles it himself. A buyer who sees only a fresh amount rings the office, and now your desk is doing accounting over the phone.

The accounting side of stage-linked money is not obvious, and it is set out in staged payments and accounting.

The three ways the demand itself fails#

Raised late, so everybody defaults at once. The stage completed weeks ago, the demands went out as one batch, and now a whole tower is overdue on the same day. Your ageing report shows a collections crisis that is really an administrative delay, and the buyers who genuinely default are invisible inside the crowd.

Raised on a stage that was not complete. Somebody read the programme instead of the site. The demand goes out, a buyer visits, photographs the slab that does not exist, and puts it in the buyers' group. You will withdraw that demand, and the withdrawal will be quoted back at you against every future demand on that project.

Delivered nowhere. The letter went by email to an address the buyer gave at booking, or landed in a spam folder, or reached the son who forwarded nothing. Months later the buyer says, truthfully as far as he knows, that nobody told him.

Delivery is half the document#

A demand you cannot prove was delivered is, in practice, a demand that was not made. Delivery is part of the record, not an afterthought.

What counts as evidence, in ascending order of usefulness: a system log that a message was sent; a delivery receipt from the channel; a read acknowledgement; a tracked physical dispatch; a reply from the buyer about anything at all, which proves receipt more convincingly than any receipt does.

Two rules follow. Send on more than one channel, because channels fail independently and the buyer's habits are not yours. And keep the addresses current — contact details confirmed at booking are stale by the time later demands go out, which is one reason the relationship needs an owner throughout, as in after the booking comes the longer job.

The reminder ladder#

Before escalation there should be a ladder, and each rung should sound different from the one before.

A courtesy reminder shortly before the due date, which assumes nothing. A reminder on the due date. A firmer one after it, restating the amount and the consequence in neutral language. Then a call from a person, because by this point the reason is usually specific — a disbursement stuck, a stage dispute, a family event — and none of those are visible to an automated message. Only then does formal escalation begin.

The rung that matters most is the one you must not send. An automatic reminder to a buyer who has already paid destroys more goodwill than three missed reminders. He paid, he has the receipt, and your system has just accused him. He will forward it to the group, and everyone behind on payment will now cite your accounting as unreliable.

That risk is not really about reminders. It is about a system that fires messages faster than it reconciles receipts, which is the general disease described in an alert that rings for everything. If the money side cannot be trusted, switch the automatic rungs off until it can. A silent ladder is recoverable; a lying one is not.

The money arrives and nobody knows whose it is#

Then the harder half. A credit lands in the bank with a narration naming the remitter's father, or a company, or nothing useful at all. The buyer's name is not on it. The unit certainly is not.

Left unmatched, that money is simultaneously received and outstanding: the buyer knows he has paid, your ledger says he has not, and the reminder ladder is running against a man who is owed an apology. Matching a credit to the right account is its own discipline, and the mechanics are in matching a bank line.

On our own side we set one rule about this and have not relaxed it. A bank line settles against an open stage only on an exact match to the paise, on the other party's name echoing back in the narration, or on the tax arithmetic working out. Never on being close. An amount that is nearly right is the most dangerous evidence in a reconciliation: right often enough to be trusted, wrong often enough to file a receipt against the wrong person. Where nothing matches, the line stays unmatched and somebody is asked.

What helps is issuing a reference with the demand and insisting it be quoted, banking narrowly so credits arrive already segregated, and treating unmatched receipts as a queue somebody owns daily rather than a month-end problem. Money coming in from buyers and money going out to contractors are separate disciplines, which is the argument in two payment ladders.

The short version#

A demand is a document plus a delivery, and the delivery is the half that gets disputed. State the stage, the certification, the components and the buyer's running position on the face of the letter, and keep evidence that it arrived.

Raise demands as stages complete rather than in batches, never on a stage the site has not certified, and never let an automatic reminder reach somebody who has already paid.

They are not the same kind of thing, and the difference is not features. It is what the record is about.

A CRM is organised around a person outside the company#

Its unit is a relationship with somebody who does not work for you and may never transact at all.

• The subject is outside your authority. You cannot assign him anything. You can only ask, offer, remind and wait.
• The horizon is months. Sometimes years. A buyer who enquired at launch and books at possession is a normal outcome.
• The hardest problem is identity. The same man enquires on a portal, at a hoarding number and through a broker, and arrives in your database three times over. Duplication and attribution — who gets credit, and therefore commission — are what a CRM lives or dies on.
• Most records end in nothing. This confuses people coming from an operations background. A pipeline where most enquiries never book is a healthy pipeline.

That last property decides the design. Because most records end in nothing, closing one has to be cheap and blameless. A CRM that makes people feel bad about closing leads accumulates a graveyard, which is also how a spreadsheet pipeline fails — leads that die in Excel.

A task system is organised around work inside the company#

Its unit is an obligation: something that must be finished by somebody who works for you or under contract to you.

• The subject is inside your authority. You can assign it, escalate it and demand a date.
• The horizon is days. A task open for months is not patient, it is stuck.
• The hardest problem is handover. Work rarely fails while somebody is doing it; it fails between two people, when one believes he has passed it on and the other has not accepted it — why tasks stall between people.
• A record that ends in nothing is a failure. The opposite of the CRM. An obligation that quietly evaporated is what the system exists to prevent.

Two systems, two opposite definitions of a healthy record. That is why the merged process is worse than either.

What breaks when you force one to be the other#

Leads modelled as tasks. Every enquiry becomes an item that must be completed. Buyers do not complete. So the list fills with items overdue through nobody's fault, the overdue count climbs past what any human reads, and the team learns that red means nothing. Once red means nothing, genuinely late internal work is red too, and invisible.

Worse, the task frame makes closure feel like failure. Nobody wants a column of items marked not done, so leads get rescheduled instead of closed, and you lose the closing reasons — the most valuable data a sales process produces.

Internal work modelled as leads. A pipeline has stages, not completion. A snag sitting in "in progress" is fine by the model, because a pipeline record can legitimately sit anywhere for a long time. There is no notion of done, therefore none of late, therefore no accountability that survives a busy week. Ageing reports become stage counts, which tell you where things are and never that something is wrong.

The tell is the same in both directions. Look at a screen and ask what an untouched record means. In a CRM, the buyer went quiet. In a task system, somebody failed. If one screen must mean both, it means neither, and people stop reading it.

The events that cross the boundary#

Here is the honest part: a builder needs both, and pretending otherwise is how offices end up with a CRM accounts hates and a task tool sales never open.

They do not need to be one system. They need to meet at a small set of events where something outside the company creates work inside it, or the reverse.

1. A booking. A buyer says yes, and work begins for accounts, CRM documentation, the legal desk and inventory. One relationship event spawns several obligations, each with its own owner and date.
2. A construction stage completing. An internal, physical fact becomes a demand on many buyers at once — the only event in the business that crosses from site to money to relationship in a single step.
3. A payment received or missed. Money changes the buyer's standing and creates internal work: reconciliation, receipting, and sometimes a collections action. Money owed to you and money you owe run on separate rails — two payment ladders.
4. A snag raised by a buyer. A relationship event that becomes site work, and must come back with an answer the buyer can see.
5. A possession or handover date. The one date that must be identical on both sides. When sales quote a month and site are working to another, the discrepancy is discovered by a buyer.

Five events. A few more in a particular office — a cancellation, a transfer — but the list is short and fits on one page.

Integrate at the events, not by merging#

The temptation is a single system: one record type, one inbox, one report. It fails for the reason above — the two record types have contradictory definitions of health, so any shared screen must lie about one of them.

What works is narrower. For each crossing event, decide four things and write them down.

• Which system is the source of truth for the fact. A booking is a sales fact. A stage completion is a site fact. Only one side may create it.
• What it creates on the other side, precisely — which obligations, with which owners and which dates.
• What flows back, and to whom. A buyer whose demand is unpaid should be visible to whoever is about to call him about possession.
• What happens when it is reversed. Cancellations, unwound bookings and withdrawn demands are the cases nobody specifies, and the ones that leave orphan work in a queue for years.

Ask a vendor to demonstrate these crossings rather than the feature list, alongside the other questions in choosing construction software. A product with a handsome pipeline and a handsome task board that cannot show what a booking does to accounts is two products in one window.

Which one we built#

Ours is a task system. It holds obligations, owners, dates, money and approvals; it has no lead pipeline, no buyer database and no broker ledger. Saying that plainly is more useful than pretending otherwise.

The one thing we do at that edge is small on purpose: a WhatsApp line marked for sales is answered from a pitch an admin writes, and every conversation lands as a card in the approvals queue for a person to pick up. That is a doorway, not a CRM.

The work a booking creates runs for years and has its own staffing problem — after the booking comes the longer job.

The short version#

A CRM tracks a relationship with somebody outside the company, over months, where most records ending in nothing is normal. A task system tracks an obligation inside the company, over days, where a record ending in nothing is a failure.

Forcing either to be the other produces a list nobody reads. Buy both if you must, but spend the evaluation on the events that cross between them — booking, stage, payment, snag, possession — because that is where the money and the goodwill leak.

Then the buyer says yes, and a relationship begins that will run for years. It is longer than the sale, it involves more money changing hands than the booking amount, and almost nobody is staffed for it.

What actually happens in those years#

Not one thing. A long, uneven sequence of small events, each of which is somebody's job on the day it happens and nobody's job in general.

• Demands and receipts. Stage after stage, each raised, delivered, chased and reconciled — the whole cycle in demand letters, reminders, and the buyer who says nobody told him.
• Loan disbursements arriving out of order. The bank pays on its own assessment and its own timetable, which is not your payment plan. Part payments land against the wrong stage and the ledger drifts.
• Changes the buyer wants in the unit. A wall, a socket position, a different tile. Each is a commercial decision, a site instruction and a cost adjustment, in that order.
• Changes to who the buyer is. A nominee added, a co-applicant removed after a family event, a transfer to an entirely new buyer, a death in the family that changes everything.
• Cancellation and refund. Rare, painful, and the process nobody has written down until the first one happens.
• Address, phone and email changes. Boring, and the reason a demand letter later reaches nobody.
• Possession, snags and the handover of documents. The end, which is really its own project.

Running underneath all of it is the thing the buyer wants most and receives least: knowing how his building is coming along.

Where it fails#

The person who sold it has left. The single most common failure, and the most expensive. The buyer's entire relationship lived in one executive's memory and phone. He resigns, and the file is inherited by nobody. The next call the buyer makes is to a number that no longer answers.

The buyer's only contact is a personal mobile number. Which means the relationship is with a man, not with the company. When he leaves he takes it, and while he is there he is answering buyer calls on a Sunday and giving answers no one else can see or check.

A promised change agreed verbally at site. The buyer visits, meets the site engineer, asks for a change, and the engineer nods. Nothing is written. The change may happen and never be billed, or be billed and never happen, and both versions surface at possession when the buyer is standing in the flat with a measuring tape.

A payment made to the wrong account. An old account, a personal account, a broker's account. The money exists but not where your ledger looks, and until somebody matches it the buyer is being chased for money he has already paid.

A change agreed in the office that never reaches site. CRM records it, the buyer pays for it, and the work is executed to the original drawing. This is the same failure as the previous one with the arrow reversed, which tells you the fault is the boundary itself, not either department.

A buyer who first hears about a delay from a neighbour. He learns from somebody in the building's group that possession has slipped. You did not tell him because there was nothing definite to say yet. What he concludes is not that you were being careful. It is that you were hiding it.

The owner has to be a role, not a person#

The correction is structural and it costs nothing to state, though something to enforce.

After booking, the buyer relationship must be owned by a role — the CRM desk for that project, the post-sales executive for that tower — and every communication must go through channels the company controls. A company number, a company email, a company account. When somebody leaves, the role is reassigned and the buyer notices nothing.

The test is simple: if an executive resigns tomorrow, can his replacement open one screen and see everything this buyer has been told, asked, promised and paid? If the answer requires access to a personal WhatsApp history, the relationship is not yours.

This is the same question as who owns an enquiry before booking. Ownership by name is convenient and fragile; ownership by role survives people leaving. The pre-booking version of the argument is in who owns the lead.

One file per unit, readable by both sides#

The second correction is that sales, CRM and site must read the same per-unit file rather than three files that agree only when someone reconciles them.

It should hold the buyer and every co-applicant, the document ladder and its current state as in from booking to agreement, the payment plan with what has been demanded and what received, every approved change to the unit with its cost and its date, every commitment made to this buyer and by whom, and the current possession position.

The load-bearing word is approved. A change becomes real when it is recorded, priced and accepted, not when somebody nods at site. Until then it is a request, and it should be visible on the file as a request so that neither party can later claim it was settled.

Silence is a message, and it is the wrong one#

The last correction is the cheapest and the most neglected. Send a proactive update on a schedule, whether or not there is news.

Buyers do not chiefly want good news. They want to know that somebody is holding their file. A quarterly note saying which stage is complete, what is next, and where their payments stand costs an hour per project and removes most of the incoming calls that make post-sales feel unmanageable.

When there is a delay, say it early and say what changed. A buyer told late concludes he was deceived, and he will read every later communication in that light. Bad news delivered early is a schedule; bad news delivered late is a grievance.

And plan the ending properly, because possession is where every loose thread arrives at once — snags raised and closed, as in the snag list that closes, alongside the transfer of documents, warranties and drawings, whose usual failures are in what makes a handover fail.

The short version#

The years between booking and possession carry more money, more paperwork and more reputational risk than the sale, and most offices treat them as an afterthought staffed by whoever is free.

Give the relationship a role rather than a person, keep every channel on company infrastructure, run one per-unit file that sales and site both read, and send an update on a schedule so that silence is never what the buyer hears. The sale is a day. This is the job.

Two habits cause this, and they compound.

The evaluation is done by people who will never use the thing. A director, an IT person, sometimes an accountant. Not the storekeeper standing at the gate at eight in the evening with a lorry waiting, the driver impatient and a phone in one hand.

And it is done against a feature list. A feature list is a list of nouns. Your office does not run on nouns. It runs on a small number of transactions that repeat all day, each with an awkward variant that nobody has written down.

Pick three transactions and follow them#

Before you look at anything, choose the three transactions that carry your money and your risk. For most builders they sit close to these:

• A material receipt. A lorry at the gate, a challan, a short delivery, and a storekeeper who must decide whether to accept it.
• A bill approval. A vendor invoice arriving, being checked against what was ordered and what actually came, and being passed by whoever is allowed to pass it.
• A payment. Money leaving against a specific bill, with whatever deduction and whatever signature your practice requires.

Now take each one end to end, and take it with your material. Your challan, with your supplier's handwriting on it and the quantity overwritten once. Your approval chain, including the partner who is usually travelling. Your worst case — the partial delivery, the rate revised in a WhatsApp message, the payment that had to move before the material did.

Three transactions followed properly will tell you more than forty features demonstrated. The method for doing that without being managed through it is in the demo is not the product.

The six axes that actually decide it#

Everything else is decoration.

Does it work where the work happens? A record is only true if it is made at the moment and place of the event. If the site writes on paper and somebody types it in the office at night, you have not bought a record; you have bought a second copy of one, arriving late. Sites have bad signal, so ask hard about what happens with the network off, and treat the answer sceptically — evaluating offline claims sets out what to test.

Can the people who must use it read it? Not the head office. The storekeeper, the guard, the junior engineer, the supervisor whose English is his fourth language. If the screen they need is dense, English-only and built for a desk, it will be used by proxy or not at all. What good looks like is in software your staff can read.

Can it prove what happened? Six months later, when a supplier disputes a quantity, you need to know who recorded what, when, and what it said before it was edited. Ask to see it on a record you created yourself, as in ask to see the audit trail.

Does it fit the approvals you already have? Every organisation has a real approval structure, and it is rarely the one on the chart. Somebody signs below a limit, somebody else above it, and a partner overrides both when a lorry is waiting. Software that insists on its own chain will be worked around within a month, and the workaround becomes the process.

Can you get your data out? Not a report. Every record, the attachments, the links between them. Test it during evaluation, not on the day you leave — getting your data back out.

What happens on the day the vendor stops answering? Vendors are acquired, change direction, or simply lose interest in a customer of your size. Ask who else runs this at your scale, and what happens to your data and your logins if support ends.

A gap you can live with, and a gap you cannot#

Every system will be missing something. The useful distinction is not big versus small; it is whether the gap makes the record unreliable.

A gap you can live with is one where the work is inconvenient but the record stays true. A field you must fill twice. A report you assemble in a spreadsheet once a month. An approval that needs an email alongside it. These cost time, and time is recoverable.

A gap that makes the record unreliable is one where the system quietly stores something that is not what happened. A receipt that cannot represent a short delivery, so the storekeeper enters the full quantity and mentions the shortage on the phone. A bill that cannot hold a disputed line, so the disagreement happens in a meeting and only the outcome is stored. An edit that overwrites the previous value with no trace.

The first kind you negotiate about. The second kind you walk away from, because every month it runs, the archive fills with confident, wrong numbers, and you will not know which ones.

Do not decide on the demo#

The demo tells you whether the product can do the work. It cannot tell you whether your organisation will do the work in it. Only a trial does that, and only if it is designed to be capable of failing — a pilot that tells you something covers how to set the pass criteria before you start, rather than after you have already spent the money.

Price belongs in the same category. The licence is the visible part of a number with several other parts, and the other parts are larger and arrive later. Ask for the whole shape of it in writing, as in what a price list does not tell you.

The single test#

After the pilot, walk to the site office and the accounts desk and look for a parallel register.

A notebook at the gate. A spreadsheet somebody maintains "for our own hisaab". A WhatsApp group where the real numbers travel. A printed sheet on a clipboard that the supervisor still fills.

If anyone is still keeping one, the tool has not been adopted. It has been added. The old system is still the system of record and the new one is a reporting layer that somebody feeds, which means you are now paying for the work twice and will eventually stop paying for one of them.

Nobody keeps a parallel register out of nostalgia. They keep it because the software cannot hold something they need, or cannot be reached at the moment they need it. Ask what that thing is. The answer is the honest review of the product, and it is free.

The short version#

Evaluate with the people who will use it, using three real transactions and your own worst documents. Judge on where it works, who can read it, what it can prove, whose approvals it fits, and what you leave with.

Distinguish a gap that costs time from a gap that makes the record untrue. And after the trial, go and look for the notebook.

That is not an accusation. It is what a demo is for. The sales engineer has walked this path a hundred times, the sample vendors have sensible names, the quantities are round and every document was created by the same person that morning.

Everything that will go wrong in real use is off that path. So an evaluation session is worth having only to the extent that you take it off the path.

Bring your own material#

Before the meeting, collect four documents from your own files. Photocopies or photographs are fine. Bad ones are better.

• A challan photograph with a smudged number. Taken at the gate, at dusk, slightly out of focus, with one figure overwritten. The one your storekeeper actually sends.
• A vendor bill whose total is wrong. Quantity times rate does not equal the line, or the tax is calculated on the wrong base. These exist in every office and they are the whole reason for checking.
• An invoice for a partial delivery. Half the order came, the invoice is for half, the order is still open. Many systems cannot say this cleanly.
• A work order with a variation on it. Extra work agreed after the fact, at a rate settled verbally and confirmed in a message.

Hand these over at the start and say you would like to see them entered. Not described. Entered.

Ask for the keyboard#

Where the meeting allows it, the person who will actually use the screen should do the typing, on the vendor's laptop, with the sales engineer watching rather than driving.

This single change tells you more than the rest of the session. You find out how many fields there are, which ones are compulsory for no reason, what the error message says when a date is entered in the Indian order, and whether your storekeeper can find the save button without being told.

When the vendor's hands are on the keyboard, you are watching a performance of competence. It is theirs, not yours.

The things to ask to see, not to be told#

Ask in these words: show me. A promise is not evidence and costs nothing.

A correction after approval. A bill was passed and the quantity was wrong. Fix it in front of you. Watch whether the old value survives anywhere, who is recorded as having changed it, and whether the approver is told. Then look at the record's history, using the questions in ask to see the audit trail.

A cancelled document. Not deleted — cancelled. A challan entered against the wrong site, a duplicate receipt, a purchase order raised and then dropped. Ask what happens to anything already linked to it.

A duplicate. Enter the same challan number for the same vendor twice. A system that accepts it silently will accumulate duplicates for years. A system that refuses it outright will eventually block a legitimate case, because suppliers do repeat numbers across financial years.

The screen the storekeeper will use. Not the dashboard. The narrow, dull, frequently used screen where a lorry gets received. Ask how many taps it takes one-handed on a mid-range phone. If the answer is a laptop, you have learnt something important.

What happens with the network off. Turn the wifi off on the demo machine, or ask them to put the phone in flight mode, and continue. Watch the entry being made, then watch it arrive when the connection returns.

The audit trail of the record you just made. Not of a sample record. The one created ten minutes ago from your smudged challan.

The export. Ask for the data you entered today to come out as a file, and open the file in the room.

Red flags#

None of these is fatal on its own. Two together should slow you down.

"That's on the roadmap." Treat a roadmap item as not existing. It may arrive, but it will not arrive on the date you need it and no part of your decision should depend on it.

A demo environment they will not let you touch. If you cannot have a login to a sandbox for a week, ask why. The usual reason is that the unrehearsed paths are not presentable.

No answer about who else runs this at your scale. You are not asking for names they cannot give. You are asking whether a builder of your size, with your number of sites, is already living with the product.

Refusal to show an error state. Every real system has failures, retries and messages. A vendor unwilling to show one is telling you the messages are not fit to be seen. Whether an error explains itself is the difference described in the app should tell you why.

A dashboard shown for longer than data entry. Charts are the easiest part of any system to build and the least used. The time split in the demo is a fair estimate of where the product's attention has gone.

Get it in writing, dated#

The demo is the only moment in the whole relationship when the vendor is answering questions rather than asking for money. After the contract, the same questions go to a support queue.

So before the session ends, agree that a written list will follow: what was shown, what exists today, what is configuration, what is custom work, what is on a roadmap, and what was said about data export and about support. Dated, and from the vendor rather than from your own notes.

You are not building a case for a dispute. You are removing the ambiguity that otherwise settles in over the following months, when everybody involved remembers the meeting differently and nobody is lying.

Then stop deciding. A demo can only tell you whether the product can do the work. Whether your organisation will do the work in it is a separate question, answered by a trial designed to be capable of failing — a pilot that tells you something. The wider decision it feeds into is in how to choose construction software.

The short version#

The demo path is clean because it was rehearsed. Take it off the path with your own smudged, wrong, partial documents, and ask for the keyboard.

Insist on seeing corrections, cancellations, duplicates, the storekeeper's screen, the network off, the audit trail and the export. Then get the promises in writing, dated, while the vendor is still answering.

It measures nothing. It measures whether an enthusiastic person, given help, can operate a system. That was never in doubt.

A pilot is an experiment, and an experiment that cannot come out badly is not an experiment. It is the last stage of choosing construction software, and the design decisions below are all aimed at one thing: making failure visible while it is still cheap.

Design rules#

One complete process, not one department. Take a record and let it travel the whole way — order raised, lorry received at the gate, bill checked, payment released. A pilot confined to the stores tells you the stores screen works and nothing about the handoffs, which is where systems actually fail.

An ordinary site, not the best one. The best site has your best people, your newest cabin and, usually, your best connectivity. If it succeeds there you have learnt that it works under favourable conditions. Choose the site with average staff, average signal and an average storekeeper.

Long enough to include a month-end. Month-end is when the awkward cases surface all at once: bills that must be booked in the right period, deliveries made on the last evening, reconciliations, the accountant's queries. A trial that ends on the twenty-fifth has skipped the hardest week of the cycle.

The vendor does not do the data entry. This is the rule most often broken and the one that ruins the most trials. If the vendor's engineer keys in the receipts, or sits beside the storekeeper prompting, you are testing the engineer. Let him train, then let him leave the room.

Pass criteria in writing, before it starts. Two paragraphs are enough, but they must exist on paper before anybody is emotionally committed. Without them, the trial ends with a discussion in which whoever argues best wins, and the person who argues best is usually the person who chose the software.

What to measure#

Five things, all of them observable without anybody's opinion.

• Did the parallel register stop? The notebook at the gate, the spreadsheet kept "for our own hisaab". If it is still being written, the tool is not the record. Everything else you measure is secondary to this.
• How long does the slowest real user take on the commonest transaction? Not the average, and not the champion. Stand at the gate with a watch during a normal delivery. The commonest transaction is done hundreds of times a month, and a slow screen is a tax collected every time.
• How many records needed a correction? And of those, how many were corrected because the person made a mistake, and how many because the system could not hold what actually happened.
• What did people do when they got stuck? This is the most informative question in the whole exercise. Did they read the message on screen and recover, ask a colleague, ring the head office, or write it on paper and carry on? The last answer is the one to worry about.
• How many questions had to go to the vendor? Count them, and keep them. After go-live those questions become a support queue with a response time, and the volume you saw in the pilot is the volume you will pay for.

How pilots lie#

The champion who compensates for the tool. One person quietly fixes the entries every evening, chases the site for what was missed, and re-keys what came over WhatsApp. The dashboard looks correct. Roll it out to twelve sites and there is one of him, not twelve, and the numbers go wrong everywhere at once. Ask the champion, privately, what he has been doing after hours.

The sample too small to hit the awkward cases. Partial deliveries, credit notes, cancelled orders, a rate revised mid-order, material returned to the supplier — these are a minority of transactions and a majority of the pain. If none occurred during the trial, the trial did not test the system. Force them: run a real short delivery and a real cancellation on purpose.

Scope creep, so nothing is concluded. Someone adds payroll in week three, then asks whether it can do drawings. Now the trial is a general enquiry, ends without a verdict, and the decision falls back to whoever is keenest. Freeze the scope on day one and write down what is out.

The pilot that succeeds and is then rolled out to strangers. The trial site was trained face to face over a fortnight. The other sites get a video call and a PDF. The pilot proved the software works when people are taught; it proved nothing about the training you are actually willing to pay for. Budget the real training before you count the pilot a success — the shape of that cost is in what a price list does not tell you.

Two conditions deserve deliberate stress while you have the vendor's attention. Take a phone to the basement or the far corner of the site and enter a receipt with no signal, which is the real form of the claim examined in evaluating offline claims. And ask for an export in the first week rather than the last.

Ending it cleanly#

Pilots that are not ended stay alive for years as a half-used login and a small monthly charge.

Decide against the written criteria, in one meeting, with the people who did the entry present rather than represented. If it passed, say what the rollout depends on. If it failed, say which of the criteria it failed, because that sentence is worth more to the next evaluation than the whole trial.

Then deal with the data. Ask for a full export of everything entered during the trial, in a format you can open, and check it before the account is closed — the tests for that are in getting your data back out. If you are not continuing, ask in writing for the trial data to be deleted, and for confirmation once it is done. Your vendor rates, your site addresses and your staff's phone numbers were all in there.

Finally, take the failures back into the next evaluation. Every awkward case the pilot found is a case to put in front of the next vendor at demo stage, which is the point of the demo is not the product. A failed pilot that produced a good list is not a wasted quarter.

The short version#

Pick one whole process on an ordinary site, run it past a month-end, keep the vendor's hands off the keyboard, and write the pass criteria before you start.

Measure whether the parallel register stopped, how slow the slowest user is, and what people did when they got stuck. Then end it in one meeting, get the data out, and carry the awkward cases forward.

This post has no figures in it, because the figures are yours and they vary enormously. What does not vary is the shape of the number. Once you know the shape, you can ask for the parts nobody volunteers.

The costs that appear on somebody's invoice#

Implementation and configuration. Setting up your companies, sites, cost heads, item masters, tax settings, approval limits and user roles. Sometimes included, often quoted separately, occasionally quoted as an estimate that grows. Ask whether it is a fixed price or a day rate, and what happens if the work takes longer than expected.

Data migration. This is nearly always underestimated, and the reason is not technical. It is that the old data is dirty. The same supplier exists three times with three spellings. Two item codes mean the same steel. Old balances do not tie. Somebody has to decide what dirty means and what to do with each case, and that somebody must be from your side, because only your side knows which of the three spellings is the real vendor. Budget for your own people's time, not just the vendor's.

Training, and retraining. The first round is planned. The second is not. Site staff turn over, particularly after a season, and a system nobody was taught is a system that gets bypassed. Ask what a training session costs after the implementation period ends, because you will buy several.

The per-user question. Ask early what a user costs, and then ask a different question: what does it cost to put the storekeeper, the gate guard, the site engineer and the supervisor on it. A per-user price is a tax on getting the record from the place it actually happens. It pushes you towards shared logins, which destroy the audit trail, or towards paper at the gate typed up later in the office, which is the failure the software was bought to fix. Ask whether there is a lighter, cheaper class of user for people who only record events.

The people who now do data entry that did not exist before. Every system creates keystrokes. If the answer to the per-user question is bad, some of those keystrokes are done by a new person in the office whose entire job is retyping what the site wrote on paper. That is a permanent salary caused by a pricing model.

Integration. Accounts, banking, attendance, whatever else you already run. Ask what is included, what is a one-time build, and who maintains it when either side changes.

The annual increase. Almost every agreement has one, and it compounds quietly for the entire life of the system.

The cost of leaving. Extraction, cleaning the extract, loading it elsewhere, and running two systems for a period. This is invisible at purchase and it is the reason people stay with tools they dislike, so it deserves a question at the start rather than at the end — the tests are in getting your data back out.

The costs nobody invoices#

These are larger than the ones above and they never appear in a comparison.

The parallel register nobody stopped keeping. If the notebook at the gate is still being filled, you are paying for the record twice: once in licence fees and once in the storekeeper's evening. Worse, you now have two histories of the same events, and when they disagree the argument costs a day. This is the single clearest signal of a failed adoption, and why it belongs in how to choose construction software.

The process bent to fit the software. A system that cannot express a disputed quantity teaches the office to record undisputed ones. A system that cannot hold a short delivery teaches the storekeeper to accept the full figure and telephone about the shortage. Nothing is invoiced. You simply have a slightly less honest archive from that month onwards, and you find out during a dispute two years later.

A slow screen multiplied. Take the commonest transaction in your office and count how many times a day it happens across all sites. Now add ten seconds to it. That number is a salary, and it recurs every year, and it never appears in any comparison because nobody measured the screen.

Support you cannot reach at the hour you need it. A lorry at the gate at nine in the evening is not a business-hours problem.

How to ask about all this#

Three requests, all reasonable, all in writing.

1. A three-year total, itemised. Licence, implementation, migration, training, integration, support, and every one-time item named separately. Not a monthly figure. Vendors quote per month because it is small; you are buying three years at least.
2. What the renewal increase has been for existing customers. Not the cap in the contract — the actual history. A vendor who will not answer this has answered it.
3. What it costs to add a person for one month at a peak. Construction is seasonal and lumpy. If adding fifteen temporary users for a busy quarter means an annual commitment for all fifteen, you will not add them, and the record will be made on paper instead.

One more worth asking, though it rarely has a clean answer: what is the price if we double our sites, and is that in writing anywhere.

What actually decides the return#

Not the feature set. Adoption.

A tool that costs more and is used by everyone at the gate produces a complete record. A cheaper tool used by three people in the head office produces a partial one, and a partial record is not proportionally useful — it is a record you cannot trust anywhere, because you never know which events are missing.

So the money question and the legibility question are the same question. If the storekeeper cannot read the screen, no licence price is cheap, which is the argument in software your staff can read. And the only honest way to find out whether people will use it is a trial designed so that they might not — a pilot that tells you something.

Say it plainly to whoever is comparing quotations: the cheapest tool that is used beats the best tool that is not.

The short version#

The licence is the visible part of a number whose larger parts are migration, training, per-user pricing and leaving. Ask for a three-year itemised total, the real renewal history, and the cost of one extra person for one month.

Then price the things nobody invoices — the parallel register, the bent process, the slow screen — and remember that adoption, not features, decides whether any of it was worth spending.

The vendor is acquired and the product is folded into something else. The price changes and the new one does not suit you. The product is discontinued. Or you simply outgrow it, and the thing that fitted one site cannot hold nine.

None of these are unlikely. The only question worth asking at purchase is what you will be holding on that day.

Three things people confuse#

A report is a view, arranged for a human being to read. It answers a question you already had, in a layout somebody designed, usually as a PDF. It is not data. It cannot be loaded into anything else, it shows the current state rather than the history, and it contains only the columns the designer thought you would want.

An export is structured rows, in a machine-readable format, that another system can be made to read. This is the minimum thing you need.

A backup is everything, including the things no report shows: the audit trail, deleted and superseded records, the internal identifiers that link one record to another, and the attachments. A backup is usually taken for the vendor's benefit, not yours, and often cannot be restored anywhere except their own software. Ask which of the three you are being offered, because all three are sometimes described with the same word.

What a real export must contain#

Five things. An export missing any of them is a partial record, and a partial record loses arguments.

• Every record, not just the current state. If a rate was revised, a quantity corrected, a bill cancelled and reissued, all of it must come out. A snapshot of today tells you what you believe now, not what you did. The reason that matters is the whole argument of append-only records.
• Attachments as files. The challan photographs, the signed work orders, the site photographs, the scanned bills. As actual files, in folders, named in a way that ties them back to the record. Not as web links into a system you no longer have an account on.
• The audit trail. Who did what, when, and what the value was before. Six months after you leave, this is what answers a dispute about a quantity, and it is the part most often missing — what an audit trail is for sets out what a usable one contains.
• The links between records. Which receipt belongs to which order, which invoice to which receipt, which payment to which invoice. Two spreadsheets with no shared identifier between them are not a record of a purchase; they are two lists that happen to be about similar things.
• The code lists. Vendor masters, item masters, cost heads, site codes, units of measure, approval roles. Without them the export is full of codes that mean nothing. A column of numbers where the item names should be is technically an export and practically waste paper.

Test it during evaluation, not at exit#

Every one of these is easy to check while somebody still wants your business, and impossible to check afterwards.

Ask for an export on day one of the pilot. Not at the end. Day one, when there are ten records in the system, so you can read the file by eye and see exactly what did and did not come out. Then open it. Actually open it, in whatever your accounts team uses, and see whether the dates survived, whether the decimals survived, and whether the vendor names came out as names.

Check whether an attachment is a file or a link. Download the export, disconnect from the internet, and try to open one photograph. If it opens, it is a file. If it does not, you are holding a pointer to somebody else's server.

Check whether a deleted or superseded record appears. Cancel a document during the trial, then export. If the cancelled document is absent, the export is a picture of the present, and every correction you ever made has been quietly dropped from your history.

Time it. Ask how long an export of a full year takes, and whether it can be run by you or only by their support desk on request. An export you have to ask for is an export you will not get during a disagreement.

Contract points worth insisting on#

In plain words, no drafting language. Four points, and any reasonable vendor will agree to all four.

1. Export available at any time, without asking. A button you can press, not a favour. The moment you most need your data is the moment relations are worst.
2. A defined format. Named in the agreement — the file types and, ideally, that it includes attachments and history. "Data will be provided in a mutually agreed format" means nothing on the day.
3. A defined period after termination. A stated number of days during which you can still retrieve everything, even if the subscription has lapsed and even if there is a payment dispute. Fix the length yourself; do not accept silence.
4. No fee for your own data. An extraction charge is a hostage fee, and the time to refuse it is before signing, not after.

One more thing belongs in the same conversation, though it is not a contract point: what happens if the vendor simply goes quiet, as small companies do. Whether you can retrieve your own data without their help decides whether that is an inconvenience or a catastrophe. The cost of ignoring all of this is a large part of what a price list does not tell you.

Documents that must survive the system#

One category deserves separate attention: anything that was signed.

A work order, a measurement sheet, an approved bill, a handover certificate. A signature stored as a flag in a database — a column saying approved by — is worth nothing once the database is gone. What you need is a document that can be checked on its own, by someone with no login, using only the file itself. That property is the subject of tamper-evident documents, and it is worth asking about at evaluation, because it cannot be added afterwards to documents already signed.

Ask the vendor a direct question: if I export a signed work order today and open it in five years on a machine that has never heard of you, can anybody tell whether it has been altered. The answer separates a signature from a picture of one.

We took that question seriously enough to answer it in our own work. A sealed work order carries on every page its number, page N of M, a fingerprint of the file, and a QR code. The page that QR reaches needs no sign-in and states only that the true document has exactly that many pages, its fingerprint, the date it was sealed and who issued it — no amounts, no contents. A vendor, an auditor or a bank clerk holding the paper can check it, and it goes on working whether or not anybody still has an account with us.

All of this belongs in the evaluation itself, alongside the other axes in how to choose construction software. Exit is not a pessimistic subject. It is the only one that is guaranteed to come up.

The short version#

A report is for reading, an export is for moving, a backup is for the vendor. Insist on an export that carries history, attachments as files, the audit trail, the links between records and the code lists.

Test all of it in the first week of the trial, while somebody still wants your signature. And make sure anything signed can be verified without the system it came from.

This is the question that separates a system of record from a data-entry screen. A data-entry screen holds what is true now. A system of record holds what was true then, and who said so, and when.

Why the question gets skipped#

Demos run forward. Raise an indent, approve it, cut an order, receive the material, pay the bill. Every person in the story does the right thing the first time.

Nothing in a demo shows somebody changing their mind at nine at night, or being asked eleven months later why a rate moved between one Tuesday and the next. That is the day the trail matters, and it is not a day anybody is thinking about while buying. It belongs with the rest of choosing construction software and it is the item most often left off.

The other reason is that buyers ask about features. A trail is not a feature you use; it is evidence you hold. Nobody demonstrates evidence.

The test, in order#

Ask for the keyboard. Then, on the system's main document — a purchase order, a work order, an indent, whatever money eventually follows:

1. Create it. As an ordinary user, with an ordinary user's permissions.
2. Approve it. As the second person, if there is an approval step.
3. Change it. Change something that matters — a rate, a quantity, the vendor.
4. Cancel it. Or reject it, or void it, whatever the word is here.
5. Ask to see the history of that one record. On screen. Logged in as a normal user of that document, not as the vendor's administrator, and not as a query their engineer runs on a laptop turned slightly away from you.

Step five is the entire test. The data almost certainly exists somewhere. The question is whether a person who is not a programmer can reach it in the middle of a disagreement, without anybody's permission.

What to look for on that screen#

• Who. A named person. Not system, not admin, not blank.
• When. A date and a time, and some indication of where the time came from.
• What it was before. "Rate changed" is not a record. The old value and the new one, side by side, is a record.
• From where. Web or phone, office or site, typed or imported. A bulk import that rewrote the whole rate list should not look identical to a storekeeper correcting one line.
• Whether the history itself can be edited. Look for an edit or delete control on the trail. Try to use it.
• What a deletion leaves. Delete the record. Does its history survive, with a line naming who deleted it, or does the whole thing stop existing.
• Whether it covers more than fields. Attachments added and removed, approvals given and withdrawn, comments, status changes.

Two more have to be tried rather than asked. Open a record somebody else created and look for the same screen: some systems show you your own history and nobody else's, which is precisely backwards — your own actions are the ones you already remember.

And get it out. Ask for the trail of one record as a file you keep. If the only way history escapes the software is a screenshot, you own the reading of it and not the record.

The questions about the vendor's own people#

This is the set that gets a longer pause.

What can support see? Most hosted systems let the vendor's staff view customer data, and usually that is how a problem gets fixed. That is reasonable. Not knowing is not.

Can they log in as me? Impersonation is a normal support tool. Ask whether it exists, who may use it, and whether it is announced.

Is their access in the trail I can read, or in a separate log only they can produce?

Can they change data directly? A correction, a data fix, a migration run against your database. Ask what that looks like afterwards.

Press hardest on the last one. A support fix that appears in the history under a storekeeper's name is worse than no history at all: a false record carrying a real person's name, and that person is the one who will be asked to explain it.

How long it is kept, and what happens when it is trimmed#

Trails grow faster than the records they describe, so every system eventually trims, archives or rolls up. Ask how long entries live, what is dropped first, and whether you are told when it happens.

Then check that answer against the life of your disputes. Construction records get questioned at final account, at an assessment, at a handover, sometimes years after the site closed. A short retention period is not wrong, but you should choose it knowingly rather than discover it.

Backups are not an answer to this#

A backup is a copy of everything the system believed at one moment. It answers can the data be recovered after a disaster. It does not answer who changed this, when, and what was it before.

To use a backup as history somebody must restore an old copy somewhere, find the same record and compare by eye. Even then the answer is "it was different last month", not "this person changed it from the site office, and here is the value they replaced". Backups protect data. A trail explains it. Only one of them settles an argument.

The discipline underneath — that a correction adds a line rather than replacing one — is set out in append-only records. The same logic applied to documents rather than fields gives you tamper-evident paperwork.

A trail nobody can read during an argument does not exist#

The dispute you are buying insurance against has a shape. Two accounts of the same event disagree, somebody is being blamed, a payment is held.

In that room a trail is only useful if the person in the argument can produce it in minutes, on their own, from a screen. If producing it needs a support ticket, a vendor's engineer and two working days, then in every dispute that actually happens, you do not have one.

That is also the difference between a trail that protects the organisation and one that protects the person who decided; what an audit trail is for argues the second is why people keep the first honestly.

The short version#

Make a record, approve it, change it, cancel it, then ask to see that one record's history on screen as an ordinary user. Check who, when, the previous value, and whether the trail itself can be edited.

Ask what the vendor's staff can see and do, and whether that sits in the history you can read. Backups are not history. A trail that takes two days and a support ticket to produce is a trail you do not have.

The good news is that you can tell them apart on a phone, in about ten minutes, in front of the person selling it to you. Of everything on the list when choosing construction software, this is among the few claims a buyer can check without trusting anyone.

The four things "offline" turns out to mean#

• It shows what you already loaded. A cache. Read-only. Open the app in a dead spot and this morning's list is still on the screen. Genuinely useful, and often the whole of what is being claimed.
• It lets you type, and then loses it. The form accepts input, the save spins or fails quietly, and a refresh or a force-close takes the entry with it. This is the common one, and it is worse than a plain refusal, because the storekeeper walks away believing the entry was made.
• It queues the entry and sends it later. The record is written to the phone, held, and pushed when signal returns. This is what most people mean when they say offline, and what a competent implementation does.
• It holds a working copy and reconciles. The device carries real data, can be worked on all day, and merges back afterwards with rules for what happens when two copies disagree. Rare, expensive, and only worth it for some kinds of work.

Ask which one it is. Then test it, because the answer given in a meeting and the behaviour of a phone in a lift shaft are different things.

The ten-minute test#

Use a real phone, not the vendor's laptop with the wifi switched off. Preferably a cheap phone of the kind your site actually carries. It is the most valuable ten minutes available in a demo, and how to run a software demo is largely an argument for spending time this way.

1. Flight mode first, then open the app. This order matters more than everything else here. Most apps survive losing signal after they have loaded. Far fewer survive being started cold with no network, and cold is the real case: a phone that has been in a pocket since morning was shut down by the operating system hours ago.
2. Open a record you have not looked at today. Last week's material issue, another site's list. This separates a real local copy from a cache of whatever happened to be on screen.
3. Create a record with a photograph. Photographs are where offline claims break. An image is large, and the queue that handles a line of text cheerfully is usually not the same queue.
4. Force-close the app. Swipe it away properly, do not just go to the home screen.
5. Reopen it, still offline. Is the entry there. Does the screen say what state it is in, or does it look identical to a saved record.
6. Come back online and watch. How long before it goes. Whether anybody is told. Whether the record ends up carrying the right time.

What to ask once you know what it does#

What happens if two people edited the same record offline? Uncommon on attendance, routine on a measurement sheet or a snag list. The system can take the last writer, keep the first, or hold both and ask a person. Any of the three can be defended. Not knowing cannot.

Whose clock is on the record? The phone's or the server's. These mean different things. A server timestamp records when the data arrived, which may be hours after the man stood at the gate. A phone timestamp records the event but trusts a device that somebody is holding.

What happens when the phone's clock is wrong? More common than people expect: a factory reset, a dead battery, a handset that has not seen a network to sync from in weeks. Ask whether the system notices the skew and what it does. An entry dated next month is easy to spot. One dated slightly early is not, and it will sit in the record looking perfectly ordinary.

How large can the queue get? Ask for the limit and what happens at it. Does the oldest entry fall off, does the app refuse new ones, or does it grow until the phone complains. A supervisor through a shutdown with no signal is not a hypothetical.

What does the user see when a queued item fails to send? Not whether it retries — everything retries. What the person sees when retrying stops working: a rejection from the server, a login that expired while they were offline, a record somebody else deleted in the meantime. If the answer is a silent drop, the system will lose entries and nobody will know which ones.

Offline changes what the record means#

This is the part that outlives the buying decision.

A record made offline was created by a device nobody was watching, at a time nobody can independently verify, and checked against rules the device could not run. Some checks simply cannot happen on a phone with no network. Is this material still in stock. Is this man still on the roll. Has this order already been received against.

So the software has two options and both cost something. Let the entry through and validate it later, which means some entries get rejected after the fact and somebody has to be shown them. Or refuse, in which case the app does not work offline for exactly the cases that matter.

Which of those it chose, and where the rejected entries surface, is the real question underneath the demo. It is worked through in offline-first as a data decision. Attendance is the sharpest version of it, because the record is about a person and money follows it a fortnight later, and attendance on a site with no signal covers the duplicate punch and the clock in more detail.

The two rules we hold ourselves to#

A queued record obeys the same rules as a live one. A punch made on a phone with no signal goes through exactly the same validation, when it finally arrives, as one made in the office on a browser. Not a lenient path for the offline case — the same path. The moment a rule has two implementations, the offline one drifts, and it drifts quietly, because nobody is watching the device that produced it.

What a phone volunteers is not evidence. Our app can sample location in the background, and not one of those samples counts toward whether somebody was present, or which site they worked at. Presence is a deliberate act by a person. A location fix is a fact about a handset, and the two are not interchangeable however convenient it would be.

Ask a vendor both questions in those words. The first tells you whether the offline path is real. The second tells you what they think a record is.

The short version#

Offline means four things: it caches, it loses your typing, it queues, or it reconciles. Ask which, then take a cheap phone, switch on flight mode before opening the app, open something you have not viewed today, make a record with a photograph, force-close it, reopen it, and come back online.

Then ask about conflicts, clocks, queue limits and failed sends. A record made offline is a weaker claim about the world than one made online. The question is not whether it arrives. It is what it means when it does.

So the question is not whether the application is usable. It is whether it is usable by the specific people in your organisation, on the phones they own, in the language they read. It is the easiest question to skip when choosing construction software, because everybody in the room can read English.

What "Hindi support" usually means#

Every vendor selling in India will say yes to Hindi. The word covers a wide range, and the range is worth naming.

• The menus only. Navigation and button labels translated; every screen behind them still in English. This is the most common version by a distance.
• Menus and labels, but not messages. The form is in Hindi until something goes wrong, at which point the failure appears in English. The user meets the translation on the easy path and loses it on the hard one.
• Static text, but not data. Everything the developer typed is translated; nothing anybody typed into the system is. Material names, unit names and status names stay as they were entered.
• The whole application, in a register nobody speaks. Complete, formal, and translated by somebody who has never stood in a site store. The words are Hindi and the sentences are not.

Ask which of these it is, then check, because nobody answers it precisely without being pressed.

How to test the language claim#

Switch the language yourself, then go looking for the seams.

Break something on purpose. Save a form with a required field empty. Enter a quantity larger than the stock. Try to approve something you are not allowed to approve. The error message is where translations end, and an error message in English is the one message that most needed to be understood.

Look at the dates and the numbers. A date shown in a form the reader does not use gets read wrongly at least sometimes. Check whether large figures are grouped the way your office writes them, and whether units appear as words your storekeeper uses or as codes from a table.

Read the register, not just the words. This is the part almost nobody checks and the part staff notice immediately. Hindi has a respectful form and a familiar one. Software written in bare imperatives — the form you would use with a child — reads as an order barked at somebody, and people resent an application that talks down to them in a way they would never accept from a colleague. The respectful form costs nothing and changes how the thing feels to use.

Check the vocabulary against the site. A translation can be correct and still useless, because the official word for a thing and the word the store shouts across the yard are different words. Somebody looking for a bilty will not find a screen labelled with the formal term for it. That is a deeper problem than translation, and the words the site already uses shows where it decides behaviour.

Find out who can switch. If changing language needs an administrator, nobody changes it. A user who cannot set their own language is using whatever the person who created their account happened to pick.

Reading is not only about language#

A large part of "can they read it" has nothing to do with which language it is in.

Sunlight. Take the phone outside at noon and look at the screen. Thin grey text on white, which looks elegant in an office, disappears entirely on a roof slab. So does a low-contrast placeholder that turns out to be the only label on a field. Contrast is not decoration.

Capital letters. A screen set in capitals reads as deliberate for a week and as shouting after that, and it is slower going for anybody who is not a confident reader — the argument in capitals are a contrast.

Tap targets. The hand using this has been working. It is dusty, it may be gloved, the phone may be wet. Small controls placed close together are a source of wrong entries, not merely of irritation.

Taps per action. Count them for the commonest task in the building — the one done all day, not the one demonstrated. Every extra tap is multiplied by however many times that job happens, and the gap between a short sequence and a long one decides whether the system gets used or worked around.

Number entry. Watch somebody enter a quantity. If the keyboard opens on letters, if the decimal point is buried, if the field rejects a comma the way the user writes it, that field will be filled in wrongly and the errors will look like carelessness rather than design.

Explanations. When the app refuses something, does it say why. A refusal with no reason teaches the user that the software is arbitrary, and arbitrary things get routed around; the app should tell you why adds that the reason must reach the reader in their own language too.

The person who cannot read comfortably#

Some of the people who will use this are not confident readers in any language. This is ordinary and it is planned for badly.

Ask what a task looks like without reading. Whether the material can be chosen by photograph as well as by name. Whether a status is carried by shape and colour and not only by a word. Whether a note can be spoken instead of typed, and what happens to that recording afterwards. Whether the flow of the screen matches the order of the physical job, so that a person can follow the shape of it from memory.

Where none of that exists the work does not stop, it moves. It goes to a call, or to somebody at the head office typing on behalf of a man at the gate, or to a group chat — which is why WhatsApp is the interface whether anybody designed for it or not.

Three things we changed in ours#

Language is a setting on a person, not a policy for a company. Automated messages go out in each person's own language rather than in one chosen for everybody. Two people on the same site can receive the same fact differently and both understand it.

The words people reply with are not translated. A short reply the system matches on stays identical in both languages, because it is a command rather than prose. Translating it would break the one thing the person had memorised.

The screen at a gate should not need a language at all. It uses pictograms and large plain numerals beside Devanagari, so somebody who reads neither language can still work it.

The test that settles it#

Hand the phone to the person who will actually use it. Say nothing.

Do not explain the screen, do not point, do not fill the silence. Give them the real task — book in this load, mark this man present — and watch where they stop. Where they stop is the answer, and it is usually not where anyone in the room expected.

The short version#

Ask exactly how much of the application is translated, then break something and see what language the error is in. Check the register: respectful forms, and the words the site already uses.

Take the phone into the sun, count the taps for the commonest task, and watch somebody type a number. Then hand it to the storekeeper and stay quiet.

What separates a working control from a picture of one is the set of cases the diagram does not draw — the approver on leave, the amount that changes after the chain started, the person who is both raiser and signatory. Spend the meeting on those. They belong high on the list when choosing construction software.

What the chain has to be able to depend on#

Start with the conditions. Ask whether a chain can vary by the amount, by the project, by the category of spend, and by who raised it.

Most systems do one. Your actual rule is all four at once: a purchase above a figure, on a particular site, in a category with an annual rate contract, raised by somebody who joined last month. If the software supports one dimension, the other three are enforced by somebody remembering, which means they are not enforced.

Then the follow-up that catches people. What happens when the value changes after the chain has started? An order raised below a threshold and then edited above it should re-enter the higher chain. A surprising number of systems keep it where it was, and the amount that needed the extra signature is precisely the amount that got fewer.

Who may change the chain#

The chain is itself a control, and a control any administrator can quietly rewrite is not one.

• Who can edit it. Not "an admin". Which named role, and how many people hold it today.
• Is the change itself approved? A control that changes without a second person agreeing is a control with a back door.
• Is the change recorded? Old chain, new chain, who, when. Without it nobody can explain why a March document took a different route from an April one.
• What happens to items already in flight? Do they follow the chain they entered or the chain as it now stands. Both are defensible. Silence is not.

The questions about people#

What happens when an approver is on leave? Three honest answers exist: it waits, somebody else may act, or it escalates on a clock. Ask which. Then ask whether a delegation carries an end date, whether the person raising the request can see it is in force, and whether the record names who actually approved rather than who the chain nominally names.

A delegation with no end date becomes permanent, and that is how one person quietly acquires the authority of three. A permission with a clock on it is the safe shape, and who is allowed to decide argues most organisations cannot state their own answer here.

Can somebody approve their own request? Test it rather than asking. Raise something as a person who also holds an approval and see whether the button is there. Then the harder versions: raise it in somebody else's name and approve it, or raise it, have it rejected, edit it, and approve the edited version yourself.

On money, is there a second signature, and can it be the same person twice? A two-step chain where one person holds both steps is one signature drawn twice. That erosion happens by convenience, not by intent — the subject of two signatures on money.

What the approver sees at the moment of deciding#

This gets the weakest answers, and it decides whether the chain does any work at all.

At the instant the approve button is pressed, what is on the screen? A title and an amount is a rubber stamp with extra steps. What ought to be there:

• The document itself, readable without opening a second system.
• What changed since the previous person approved it.
• The history, including any earlier rejection and its reason.
• The position on the head — what is already committed against this budget, this project, this vendor.
• Anything outstanding on the other side — an open dispute, an overdue balance, a quality issue not closed.
• What this step is for, in one sentence, so a new approver knows what to check.

Then ask the same about the phone. Most approvals happen on a phone, between other things, and if the phone screen carries less than the desktop one, the approval that actually occurs is the shallow version.

After the fact#

Can an approval be withdrawn? Between the approval and the order leaving the building there is usually a window. Ask whether it exists, who may use it, and whether using it leaves a line in the record.

What happens to a record approved and then edited? This is the important one. If a rate can change after approval and the approval stays attached, the approval means nothing. Three answers are defensible: the edit is refused, the approval is voided and the chain runs again, or the edit is allowed and marked so the next person sees it. Ask which, then change a rate on an approved order and watch the screen.

How approval chains fail in practice#

They rarely fail by being wrong. They fail by being ignored.

• Too many steps. Each approver assumes the others read it, so everybody signs. A few steps genuinely read catch more than many that are not.
• A step whose owner does not know what they are checking. Ask an approver what they look for. If the answer is "that it is correct", that step is a delay wearing the costume of a control.
• The out-of-office stall. Nothing is refused. It sits, and moves when somebody rings. The commonest failure and the hardest to see, because a stalled item produces no event — why tasks stall between people.
• Escalation that needs an accusation. If moving a stuck item upward means naming a colleague, nobody moves it, and management hears of the problem only once it is unfixable; escalation without shame designs that requirement out.
• The override that becomes the route. Used once for a real emergency, then for something merely urgent, then for anything raised late on a Friday. Given a year, the bypass is the process and the chain is decoration.

Two of these cost us real work#

Delegation is bounded and never lowers the floor. A stand-in is named for a window with an end date, is revocable, and cannot turn two signatures into one.

Moving a reviewer re-addresses the review. When a task's lead changes mid-review, the new reviewer is knocked with the brief the submission carried, and the previous one is told nothing is owed. Quietly swapping queue rows leaves two people each assuming the other has it.

What good looks like#

The fewest steps that each mean something. Every step added dilutes the attention of the ones already there.

Every step named for what it checks, not for the rank of whoever signs. "Confirms the rate matches the contract" tells a new approver what to do; "director approval" tells them only that they are senior enough.

Every bypass recorded rather than silent. An override that writes a line, names the person, asks a reason and appears on somebody's screen next morning stays rare. A silent one becomes the default.

The short version#

Ask whether a chain can depend on amount, project, category and raiser at once, and what happens when a value changes mid-flight. Ask who may edit the chain, and what happens on leave, on self-approval and on an edit made after approval.

Then ask what the approver actually sees at the moment of deciding, and on a phone. Fewest steps that each mean something, every step named for what it checks, every bypass written down.

Templates, buttons, delivery reports and reply handling all follow from that answer, and getting it wrong costs relationships that took years to build. It belongs on the list when choosing construction software, not settled by whichever option the vendor happens to have built.

The single company number#

All outbound traffic leaves from one business number. Everyone who deals with you sees the same identity.

What that buys you:

• Continuity that survives people. The number belongs to the organisation. Staff change; the thread does not.
• A record by default. Sent, delivered, read and kept, on the company's side of the line, without asking anybody to cooperate.
• One place to change things. A template edited once changes every message that follows it. One switch turns a category of traffic off.
• A clean ending. Somebody who has left cannot keep talking to your vendors as though they still work here.

What it costs:

• Replies land in one inbox, and somebody must route them. If nobody owns that inbox, replies disappear into it, which is worse than never inviting one.
• Personal continuity is lost. The vendor who has dealt with the same purchase officer for years now hears from a company, and replies to a number that does not know him.
• Tone flattens. A statement from a company number reads as a statement. The same words from the man he has been arguing with about rates read as a nudge between two people.

One number per person#

Each person sends from the working identity the other side already has in their phone. The vendor sees a name he recognises.

The gains are the mirror image. A reply reaches somebody who knows the history. The recipient can ring the same number and get a human. The tone matches the relationship, so a chase lands as a chase and not as a form letter. Nothing has to be routed by anybody.

The costs are real and they are usually discovered late.

• The organisation's conversation lives on personal handsets. When the person leaves, so does the thread, and with it the reason a rate was agreed.
• There is no record unless one is deliberately kept, and "deliberately kept" means somebody designed for it before the first message went out.
• Work and home share a screen. A supplier messages at eleven at night about a lorry, and the family group is two swipes away.
• Nobody can cover. On a day of leave, the vendor's message sits unread on a phone in a drawer, and the sender has no way of knowing.
• The number is portable. A relationship held entirely in one person's handset can be hired away.

Which traffic belongs to which#

The mistake is not choosing the wrong model. It is choosing one model for everything.

A company identity should carry the traffic that is periodic, identical in shape, or generated by the system: a price revision, a site closure, a holiday notice, statements and ledgers, an approval waiting, a document ready, a payment released. None of these need a person present, and all of them benefit from being uniform.

The risk on this side is volume. A company number that sends every event becomes a channel people mute, and a muted channel is worse than none, which is the argument in an alert that rings for everything.

A person should carry the traffic where the answer depends on trust rather than information. A negotiation — rates are agreed between people. A chase: where is the lorry from a company number is a form letter, and from the man who placed the order it is a question with somebody standing behind it. A site instruction, where the supervisor telling a contractor to stop a pour needs to be the supervisor.

A system that handles only the first kind does not remove the second. It pushes it onto personal phones, unrecorded, which is roughly what already happens in most offices, and why WhatsApp is the interface whether anybody designed for it or not.

How we settled it#

Both, with a rule about which.

A person can link their own work number, and their documents and signature requests then leave from it — the vendor sees the colleague they know. Those personal lines are structurally barred from carrying company-wide announcements: a broadcast can never go out over somebody's own number, whatever anybody configures.

For a message to an outside number, we send from the line on which the last conversation with that number travelled. If that line cannot send, it goes from the office number and says nothing about why. A vendor need not be told which colleague was unavailable.

The questions to ask the vendor#

• Where does a reply go? Into a shared inbox with a named owner, onto a screen inside the software, or nowhere. "Nowhere" is a real answer and it is rarely volunteered. Worse is a reply that arrives but is routed as general noise when it was actually a request, which is the failure in filed as chatter.
• Is the conversation kept when the person leaves? For a company number, usually yes. For anything per-person, ask precisely what survives the handset, and ask before the first resignation rather than after.
• Can a person opt out, in both directions? Can a staff member decline to have their personal number used for company traffic. Can a recipient stop receiving messages, and is that honoured permanently and across every kind of message, not only the one they complained about.
• What happens to a personal message that lands in a business thread? Because it will. Somebody's family will message the wrong number, a vendor will send a wedding invitation. Ask whether it is stored, who can read it and whether it can be removed.
• What exactly is stored, and for how long? Text, attachments, numbers, delivery and read status. Read status especially, because it is a fact about a person and it will eventually be produced in an argument about whether somebody saw an instruction.
• What happens when a number changes? Ask how the history follows, and what becomes of messages already queued to the old one.

Consent, and rooms you were not invited into#

Two lines are worth holding whatever the software permits.

Ask before you add anybody. A number that reached your system through a contract, a visitor register or a group somebody was once in is not permission to send them things. Asking costs one message and settles it permanently. The rules here move from time to time, so verify the version in force where you operate — the practice stands on its own regardless.

Read only what was addressed to you. If the software can see a group because a staff member's number is connected to it, it can also see conversations that have nothing to do with the company: a family group, a friend's chat, a discussion among workers. Keep only what a record genuinely requires, and be able to say plainly which is which. A person who suspects the system reads everything on their phone will carry a second phone, and then you have neither the record nor the trust.

The short version#

Broadcasts, statements and system alerts belong to a company identity. Negotiations, chases and site instructions belong to a person the other side knows. Choosing one model for both is the mistake.

Ask where a reply goes, what survives somebody leaving, and what is stored and for how long. Then ask before adding anybody, and read only what was addressed to you.

A payment moves when three documents agree and a person with authority signs. That is the whole machine. The order says what was agreed. Some record on their side says what arrived. Your bill says what is owed. When the three agree and the signature happens, paisa moves.

So every delay is one of four things, and none of them is fixed by asking when the payment will come.

The four places a bill stops#

• Your bill does not match their record of what arrived. A quantity, a rate, a unit or an item code is different. The comparison they run is three-way matching, and when it fails it usually fails quietly. Nobody rings the supplier to say that line four is short by two bags.
• Their record of what arrived does not exist. The material is on site and half of it is already in the slab, but no goods receipt note was written when the lorry came in. There is nothing to compare your bill against, so there is nothing anybody is willing to approve.
• The bill reached the wrong person. It is with a site engineer who cannot approve it, in a drawer waiting for somebody to carry it to head office, or with an accounts clerk who is waiting for the site to confirm and has not told the site so.
• The person who must sign has not been asked. Everything agrees, the file is complete, and it is sitting in a queue behind other files because nobody has put it in front of the signatory.

The first two you prevent. The second two you detect. The skill is telling them apart from the outside.

A fifth place, nobody's fault#

A fifth state belongs to none of the four, and we found it in our own software. A photographed challan becomes a receipt row matched against open purchases — and our matcher considered only purchases not yet paid. Money here often moves before dispatch, so by the time material arrived the correct purchase was already paid, and never a candidate. The challan matched nothing, and a challan matched to nothing appears on no screen.

Nothing failed loudly. If your bill sits in a state nobody on their side can name, ask about this class of fault: not a wrong rule, but a list of cases written before somebody thought of yours.

Preparing a bill that cannot be held#

Write the bill in their language, not yours. Everything on it should be findable in their system without a translation step, because the person checking it has a stack of other files open and will not translate.

Quote their order number on every page. Not your quotation number, not your job number. If the order was amended, quote the amendment as well.

Use their item codes and their descriptions. Your godown calls it one thing and their order calls it another. Bill it the way the order says it and put your own code in brackets after, if your accounts need it.

Bill against what their site acknowledged, not against what you dispatched. This is the largest single cause of held bills. You sent a full load; the gate signed for less. Bill what was signed for and raise the shortfall separately as a written claim. A bill that exceeds the receipt does not get part-paid — it gets returned, and starts again at the back of the queue.

Keep the unit the order used. A rate agreed per tonne and billed per quintal is a factor of ten, and on the page it looks like an ordinary line.

Attach the acknowledged challans. Not your office copies — the ones with a name and a signature on them. A bill with its challans attached can be checked by one person at one desk. A bill without them starts a search across two offices, and searches get postponed.

Show the arithmetic. Quantity times rate, then tax, then the line total, then the sum. Bills are typed by people and the arithmetic is wrong more often than anyone admits. Be wrong once and every future bill of yours is checked twice.

The same checklist from the buyer's desk is reconciling a vendor bill, and reading the other side's version is the fastest way to stop failing it.

Chasing in a way that produces information#

Most chasing produces nothing because the question has no useful answer. "When will it be paid?" can be answered honestly with "soon" by a person who has no idea, and both of you put the phone down having learned nothing.

Ask instead which of the four states the bill is in. Is it checked and matched? Is it waiting on a receipt from site? Is it with somebody for approval? Has it gone for payment? Four states, and the person on the phone can usually answer in one word.

Then ask for a name. Not a department. The bill is with a person, that person has a desk, and once you know the name you can ask a specific question next week instead of the same vague one. A file whose location is known moves faster than one whose location is not, because somebody now owns the answer.

And put every verbal agreement into a written line the same day. A message that says as discussed today, the rate for the balance quantity is agreed at the revised figure and I will supply against it from tomorrow costs nothing to send and becomes the only surviving record of a conversation that two people will remember differently in March. Send it while the call is fresh. The absence of a reply is also part of the record.

Fixing your own side first#

Three habits remove most of your own contribution to the delay.

Get challans acknowledged by somebody authorised to acknowledge. A watchman's signature is proof that a vehicle arrived. It is not acceptance of the quantity, and at bill-checking time the difference matters. Find out who at that site is permitted to receive material and get their name on your copy.

Confirm a rate change in writing before you supply against it. A revised rate agreed on a call and never written down will be paid at the old rate, and you will be arguing about it from a position of having already delivered. The order is the document that decides the rate. If the order was not amended, the rate did not change.

Keep a ledger you can produce in one minute. Bill number, date, order number, amount claimed, amount received, balance. When your figure and theirs differ — and they will, over a year, for reasons on both sides — the party who can produce a dated statement immediately sets the terms of the discussion. That is the whole argument in when your ledger and theirs disagree.

Deductions are a separate matter from delay and worth not confusing with it. Money withheld on purpose is not a stuck file, and paying less than agreed covers that case.

The short version#

A bill is not a request. It is a document that has to survive a comparison made by a stranger who is not looking for a reason to help you.

Write it in their numbers, against what their site signed for, with the challans attached. Then chase by asking which of four states it is in and whose desk it is on, rather than when the money will come. The bill that cannot be questioned is the bill that gets signed.

From the supplier's side it is a different object. It is the only piece of paper you will ever hold that proves the material left your godown, reached their gate, and was taken in by somebody. Everything you are owed rests on it. Written carelessly it starts an argument. Written properly it ends one before it begins.

What earns its place on the page#

A challan is not a form to be filled. Every line on it is there because some line was once missing.

• Their order number. The first thing anybody looks for and the first thing usually absent. Without it the challan belongs to no order and the accounts department cannot attach it to anything.
• Their site, described in their words. Not "Site 2" as your dispatch clerk calls it. The site name that appears on their order, because that is the name their file is under.
• The material, described the way their order describes it. Your trade name and their specification are different strings, and a storekeeper matching by eye at a gate will not reconcile them.
• Quantity in the unit the order used. Bags, tonnes, cubic metres, running metres, numbers. Change the unit and you have created a conversion that somebody must perform under a lorry in the sun.
• The vehicle number. It ties the paper to a physical event that a gate register and a security camera can both confirm.
• The date and the time of arrival. Time matters more than people think — a load booked in after cut-off, or on a day the site claims it was closed, is defended by a time.
• Space for a name, a signature and a designation. Three fields, not one. The middle one alone is nearly worthless.

The details nobody tells a new supplier#

Get a name, not a scribble. A signature that cannot be read is a signature nobody will own. Print the name below it, in your driver's hand if necessary, and the designation beside it. When the query comes, you are naming a person rather than waving an illegible mark.

Know which fact you are collecting. A security guard's signature is a fact about arrival: this vehicle came in at this time. It is not acceptance of quantity or condition, and no amount of insisting will make it so at bill-checking time. If quantity matters — and it always matters — the signature you want is the storekeeper's or the site engineer's. Both signatures are worth having, for different reasons, and a gate register people actually keep is where the first one lives.

Retain the signed copy, not the copy you wrote. This is the mistake that costs the most. A three-part challan is only useful if the part that comes back to you is the part with their signature on it. A file full of your own unsigned copies proves that you printed some paper.

Photograph the signed copy at the gate. Before it goes back into the driver's pocket, before the lorry moves, while the vehicle number is still visible. Drivers lose paper. Paper gets wet. A photograph with a timestamp, sent to your own office on the spot, is a record that exists independently of whether the paper survives the return journey.

Record a short delivery on the challan itself, at the gate. The site says four bags are damaged, or the count is under. Do not agree to fix it later. Write the accepted quantity on the challan, have it initialled, and supply the balance against a fresh challan. "We will adjust in the next load" is a sentence that has no document behind it, and in three months it will be your word against a ledger.

Number it uniquely, in your own series. One unbroken series, no gaps, no restarts, no two challans with the same number in different books. A number that repeats destroys the ability of anyone — including you — to say which delivery is being discussed.

Three situations that go wrong#

The site refuses to sign. It happens: the storekeeper is absent, the engineer says he is not authorised, the material is disputed. Do not let the lorry unload on a promise. If it must unload, write on the challan what was actually delivered, note the refusal and the name of the person who refused, photograph it, and send a message to your contact at their office the same day stating what was delivered and that a signature was declined. An unanswered written statement made on the day is much stronger evidence than a memory produced later.

Unloaded, then questioned. The load is off the vehicle, the lorry has gone, and now the count is disputed. This is why the count happens before the vehicle leaves and why the driver waits. Once material is in a stack with other material, nobody can prove what you brought. If quantity is measured rather than counted — sand, aggregate, earth — then agree the method before you deliver, and understand what measured and docketed quantity actually commits both sides to.

The weighbridge slip disagrees with the invoice. Two weighbridges rarely agree exactly, and neither side is necessarily cheating. Decide in advance whose bridge is the reference, keep both slips with the challan, and treat a difference beyond the ordinary as a question to raise the same day rather than at bill time. A gap questioned on the day is a calibration discussion. The same gap questioned in month four is an accusation.

Filing so it can be produced#

A challan that cannot be found is the same as a challan that was never signed. File the signed copies by project and by month, keep the photographs in one place with the challan number in the file name, and attach them to your bill so the person checking never has to ask you for anything. That habit is the whole argument in keeping your own copy, and it is also what makes the difference between a bill that passes and a bill that waits, which is the subject of getting paid on time.

The short version#

The challan is your evidence, not their paperwork. It needs their order number, their site name, their unit, a vehicle number, a time, and a real name against the signature.

Keep the copy that came back signed, photograph it at the gate, write short deliveries on the spot rather than agreeing to adjust later, and never issue two challans with the same number. Everything you are owed is attached to that piece of paper.

The rate is the least dangerous number in it. What decides whether the job makes money is a handful of clauses that read like boilerplate, and the difference between the two versions of a clause is often four words. The distinction between this document and a purchase order matters too, and work order or purchase order is worth being clear about before you read further.

What you are being asked to do#

Scope. What the work is. Usually written well, because it is the part everybody discussed.

Exclusions. What the work is not, which is more important and almost always thinner. Every item you assumed was somebody else's job needs to be named here. Cleaning up. Making good after another trade. Cutting and patching. Curing. Watchman. Storage. If it is not excluded, it is included, and the argument you lose is the one where both of you assumed the other had priced it.

Material. Who supplies each item, who transports it, who stores it, who insures it while it sits at site, and — the one that quietly costs money — who bears the wastage. If the order is silent on wastage on employer-supplied material, you will be debited for a figure somebody else calculates.

The rate, its unit, and what it includes. A rate means nothing until you know what it swallows. Taxes. Transport. Loading and unloading. Lifting to floor level. Scaffolding. Water. Power. Tools. Each of these has been the subject of a dispute on somebody's project this month. And the unit itself decides more than people expect — the unit of measure is the line to read twice, because a rate agreed in one unit and measured in another is not a small error. Whether the rate survives contact with the site is a separate question, covered in quoting a rate you can live with.

How you actually get paid#

Measurement method, and who measures. By what method is the quantity arrived at — from the drawing, or from the work as built? Deductions for openings, at what threshold? Who takes the measurement, who is present, and what happens when the two of you disagree. This clause decides the size of every bill you will ever raise on the job.

Variations. How extra work is ordered, and how it is priced. Two separate questions. Pricing is either at the order's rates, at rates derived from them, or agreed case by case — and if it is the third, agreed before the work or after it. Then the sharp part: does a verbal instruction count? If the order says variations must be in writing, then a site engineer telling you to do something is not an order, however senior he is, and you will discover that at final account.

Payment terms, and what triggers a bill. Not just the period. What event starts the clock — submission of the bill, certification of the bill, or receipt of some other document? A payment term that runs from certification with no time limit on certification is not a payment term.

Retention. How much is held, on what, and — the part usually left vague — what event releases it and when. Its mechanics are in retention money, and the clause to look for is the one naming the event, not the duration.

Advance. How much, against what security, and how it is recovered: proportionally from each bill, from a stated point, or in a lump. The recovery schedule changes your cash position on every bill, not just the first. Mobilisation advance covers what the money is really for.

When things go wrong#

Time. The completion date, and what counts as grounds for an extension. Delay caused by the employer, by another contractor on the same floor, by drawings that arrived late, by material that was to be supplied and was not. If the extension clause lists no grounds, every delay is yours.

Penalties. What is charged, on what base, and against what ceiling. A penalty with no ceiling is an unbounded liability on a fixed-value job.

Safety and statutory responsibilities. In outline: who is responsible for site safety, for workers' welfare and insurance, for registrations attached to the work, and for deductions the employer must make from your payments. Do not accept a clause that assigns you an obligation you have not read the current text of. Obligations in this area change, and you should verify the version in force with your own advisor rather than trust the order's summary of it.

Termination. On what grounds either side may end the contract, what notice is required, and — the clause people forget — how you are paid for work done and material brought to site at the point of termination.

The three lines usually missing#

Across most orders that later go wrong, the same three absences appear.

1. The measurement basis. Named nowhere, and so decided by whoever holds the tape at bill time.
2. Variation pricing. The order says variations shall be instructed in writing and says nothing about how they will be valued.
3. What "completion" means. Physical completion, handover, or the end of a defects period. Retention release, penalty stop and final bill all hang off this word, and the three of them can hang off different dates if nobody defines it.

Ask for all three before signing. They are cheap to add on the day the order is drafted and impossible to add afterwards.

Orders that arrive late, and amendments#

Work often starts before the order arrives. That is normal in this trade and it is not, by itself, a disaster — but the order that eventually arrives will describe the job as somebody at head office understood it a month ago, not as it was actually instructed on site. Read it against what you have been doing, and raise the differences in writing before you sign, not at the first bill.

An amendment must be a document. A rate revised in a message, a scope extended in a meeting, a deadline moved on a call — none of these amends an order. Get an amendment sheet with a number, referencing the original order, signed by the same authority. And check that authority: an order signed by somebody without the power to sign it is a problem you will not discover until payment, when a person you have never met declines to approve a commitment their organisation did not make.

The short version#

The rate is the number everybody reads and the clauses around it decide the profit. Exclusions, wastage, what the rate includes, how quantity is measured, how a variation is priced, what releases retention, and what "completion" means.

Read those before you sign. Insist that amendments are documents, and check that whoever signed the order was entitled to.

What just happened, and is it worth anything six months from now?

The answer depends entirely on which of three quite different things the app did, and most people signing have never been told which one they are using.

Three things called a signature#

A photograph of a wet signature, pasted onto a page. Somebody once signed a blank sheet, it was scanned, and now that image is dropped onto documents. This proves nothing about this document. The image can be lifted off one page and placed on another by anyone with the file, and it carries no information about when it was applied or by whom.

A mark drawn on a touchscreen. You actually signed, at that moment, with your own hand. The mark is genuine as an act. Whether it is attached to anything depends on what the app recorded around it — who was logged in, when, from where, against which version of the file. Drawn on paper with a witness present, a signature draws its strength from context. On a phone the context has to be manufactured deliberately, and many apps do not bother. A drawn mark stored as a picture on a page is only slightly better than the pasted photograph.

A cryptographic signature. The document is reduced to a fixed value computed from its exact contents, and that value is signed with a key held by one person. Change one character of the document afterwards and the value no longer matches, so the signature no longer verifies. This is the only one of the three that binds a specific person to a specific set of bytes and detects any later change to them. The general principle is in tamper-evident documents.

What each of these counts for in a dispute is a question of law, and law differs by jurisdiction and changes. Nothing here is legal advice. If you are about to rely on an electronic signature for something that matters, verify the position in force where you are with your own advisor, and ask specifically which of the three your system produces — the vendor will usually answer that question honestly if you ask it precisely.

Signing something at site#

You will not always have a choice about the tool. You do have a choice about how you use it.

Read the whole document, not the page you were sent. A single page photographed and forwarded is not a document. It is an extract chosen by somebody else. Ask for the file.

Check the page count. If it says one of nine and you have one page, you have not read eight pages of a thing you are about to be bound by. This is the most common way people sign a scope they never saw.

Keep the version you signed. Not the sender's promise to send it afterwards — the actual file, downloaded to your own storage, on the day. If the only copy of the signed document lives in the other party's system, then the signed document is whatever their system says it is. That principle is the whole of keeping your own copy.

Note the date and how it reached you. The message that carried it, from whom, at what time. Keep the message. The covering note often says something the document does not — as discussed, rates unchanged — and that note is part of the record.

Do not sign a scope you have not read because the sender is waiting. Urgency is the standard technique for getting signatures onto documents that would not survive a slow reading. A work order deserves the attention described in what a work order should say whether it arrives on paper or as an attachment.

If you are the one asking for a signature#

The obligations run both ways, and a supplier who collects signatures from site staff carries most of them.

Send the whole file. Every page, in one document, not a page at a time as questions arise.

State plainly what is being signed. "Please sign" is not a statement. "This is the acknowledgement of quantity received today against your order, four pages" is. A person who signs without knowing what they signed will say so later, and they will be believed.

Make the signed copy available immediately. Both sides should hold the same file, from the same minute. A signed document that only one party has is a document the other party can plausibly dispute.

Never allow a signature to be applied to something that can afterwards change. This is the one that matters most and gets ignored most. If the document is a record in a database and the signature is a flag on that record, then editing the record after the signature leaves a signed document that nobody signed. The fix is not a policy telling people not to edit. The fix is that the signed thing is a frozen copy, and any change produces a new version requiring a new signature — with the old one still visible. Why the history has to survive is the argument in what an audit trail is for.

Do not let one login stand for two people. Where a document needs two approvals, the system must know that two distinct people signed it, at two times, from two accounts. A shared login collapses that into one act, and two signatures on money explains why the second signature exists in the first place.

How ours works#

Since we ask people to sign from phones, here is what we do.

A document on a task goes to the people on it and to named outside vendors, each with an unguessable link — a vendor's arrives on WhatsApp — signed with a finger on their own phone. A saved mark can only be applied by a session signed in as that person: not by an administrator, not by a helpful colleague. That refusal is what makes storing one safe.

Marks are drawn first and every page stamped afterwards, so the fingerprint each page carries belongs to the signed document, not the blank one. A round can be stopped mid-flight with a reason, killing every outstanding link; a completed one cannot. Asking again on a sealed document makes a fresh copy rather than overwriting what was vouched for.

Verifying, from paper#

Most of this still ends on paper. Somebody prints the signed document and files it, and the printed copy is what gets produced in a meeting.

A printed page carries no proof of anything by itself. What makes it checkable is a reference on the page that can be looked up independently — a document number and a short verification code, or a code that resolves to the stored version. Then the copy in a file can be held against the copy in the system, and if they differ, that fact becomes visible instead of being argued about.

Without something of that kind, a printed electronic signature is just an ink pattern on paper, and the person disputing it has only to say the file was different when they saw it.

The short version#

Three quite different things are called signing on a phone: a pasted image, a drawn mark, and a cryptographic signature that binds a person to exact bytes. Only the third detects a later change, and what any of them counts for legally is something to verify where you are, with your own advisor.

Read the whole file, check the page count, keep your own copy of what you signed, and never let a signature sit on a document that can quietly change afterwards.

Not a better record than theirs. Your own. A separate one, made by your side, at the time.

Why the copy decides the argument#

At final account time nothing is settled by who is right. It is settled by who can produce a dated document the other side cannot contradict.

That sounds cynical and it is simply how the meeting goes. Two people remember a conversation from eleven months ago differently, both honestly. One of them opens a file and reads out a challan with a signature and a date on it. The discussion is over, and it was over because of the file, not because of the memory.

The asymmetry is the problem. The larger party has an accounts department, a filing convention, a system, and somebody whose job is to keep it. The smaller party has a phone with four thousand photographs on it and a storekeeper who left in March. Both sides forget equally; only one side can prove anything afterwards.

Every hour you spend on this is bought at the rate of the disputes it prevents, and it will feel wasted right up until the year it does not.

What to keep#

• Signed challans. The copies that came back with a name on them, not the ones you wrote. This is the foundation of everything else, and the challan that protects the supplier is about getting them signed properly in the first place.
• The order, and every amendment to it. In one file, in order. An amendment sitting in a different folder from the order it amends will not be found by the person who needs it.
• Measurement sheets agreed at site, with a name against them. The quantity you and their engineer arrived at together, on the day, with his name on it. Not your calculation of it afterwards.
• Photographs of work before it is covered. Reinforcement before the pour, conduits before plaster, waterproofing before screed. Once it is covered, the only evidence it was done correctly is the photograph, and a site photograph is a record covers what makes one usable as evidence rather than decoration.
• Dated notes of verbal instructions. Sent as a message the same day, so there is a timestamp that is not yours to set.
• Your own bill register. Bill number, date, order, amount claimed, amount certified, amount received, balance. One row per bill, kept current.
• Payments actually received, against what you claimed. These diverge slowly and for many small reasons, and by the time anybody looks the gap has a history that nobody can reconstruct. That is the situation when your ledger and theirs disagree describes.

Present is not the same as usable#

Most small firms already have the records. They cannot find them, which amounts to the same thing on the day it matters.

One place. Not one place per person. If challans are on the driver's phone, measurements are in the engineer's notebook and bills are in the accountant's laptop, the firm has no records — three people have some.

Named consistently. Project, then date, then what it is. Any convention works as long as it is the same one every time, because the thing you are buying is the ability to sort a folder and see a sequence. The value is not in the tidiness. It is in a gap being visible.

Not only on the phone you drop. Phones are lost, stolen, replaced and dropped into freshly poured concrete. If the only copy of a year of challans is on a handset that goes into a drain, the year is gone. A copy somewhere else — a laptop, a drive, an account that syncs — costs nothing and is the difference between an inconvenience and a catastrophe.

An hour a month, not a search in year three. Filing is cheap while the event is recent and the person who was there is still in the office. It is expensive after the storekeeper has left and nobody remembers which site the load went to. An hour at month end, filing what accumulated, is the whole system.

Never overwrite. When a measurement is revised, keep the earlier one next to it. A file that only holds the latest version cannot show what was agreed and then changed, which is precisely the fact in dispute. That instinct is the subject of append-only records, and the reason it matters is the same reason an audit trail exists.

Writing back is the cheapest habit in the trade#

Most instructions on a site are verbal. Somebody senior says do it this way, or add this, or stop that, and walks off to the next problem. Nothing is written, because writing it would be slow and slightly rude.

Send a message the same day. As instructed by you this morning at the third floor, we are shifting the shuttering to the other bay and will resume the slab on Thursday. Three lines, no argument in them, no demand.

What you have done is convert a memory into a record. It has a timestamp you did not set. It went to a person who could have corrected it and did not. In eight months, when the delay to the slab is being discussed, that message is the only surviving account of why, and its absence of a reply is part of it. Silence against a written statement made on the day is much harder to walk back than silence against a claim made later.

The same technique covers rate changes agreed on a call, scope added in a meeting, and material accepted with a condition attached. Write it back the same day, plainly, without heat.

This is not about distrust#

It reads as suspicion and it is not. Both sides forget. Their site engineer who agreed the extra work is transferred; your supervisor who did it leaves; the accounts clerk who understood the arrangement retires. Nobody is lying at the meeting. There is simply nobody left who was there.

Records are not a weapon against the other party. They are a defence against time, and time takes both sides equally.

The short version#

Hold your own record of every event, made by your side, at the time. Signed challans, the order and its amendments, agreed measurements with a name, photographs before things are covered, verbal instructions written back the same day, and a bill register you can produce in a minute.

One place, named consistently, copied off the phone, filed for an hour each month. Not because anybody is dishonest, but because in three years you will be the only person in the room who can produce anything.

That is not a compliment. It is a description of the job. What the engineer wrote down happened. What the engineer did not write down is available to be argued about, later, by people who were not there.

So what to record is not a clerical question. It decides what will still be true when everyone's memory has gone soft.

What must be recorded, because it will be asked about#

Start with the work itself.

• What work was done, and where exactly. Not "slab work". Which element, which grid, which level, which block. A location that only makes sense to the person who wrote it is not a location.
• Quantities measured, and by whom. A quantity has an author. Two people measuring the same pour will differ, and knowing who held the tape is half of settling that difference later.
• Material received, and its condition. What arrived, how much, and what state it was in at unloading. Damage noticed after the lorry has left the gate is your damage.
• Labour present, by agency. Not a single headcount. So many from this contractor, so many from that one, in these trades.

Then the entries that decide disputes.

• Weather, or any event that stopped work. The hours lost and the reason. Delay claims are built out of these entries or they are not built at all.
• Instructions given and received, with who gave them. An instruction with no author is not an instruction. It is a rumour that cost money.
• Anything covered up before it could be inspected. Reinforcement concreted over, a service buried, a joint plastered. Record it before it disappears, because afterwards your note is the only evidence there is.
• Any deviation from drawing, with who approved it. Deviation is normal on every site. The unapproved deviation is the one that becomes expensive.

What should not be recorded#

This half matters as much, and almost nobody is told it.

• Opinions about people. That a supervisor is careless, that a gang is lazy, that a vendor cannot be trusted. These sentences are read out in rooms you will not be in, years after the person has changed. They damage the writer as much as the subject, and they prove nothing.
• A guess written as a measurement. If the pour was not measured, the entry is that it was not measured. An estimate recorded in the same column as a measurement contaminates every figure around it.
• A quantity copied off a docket and presented as measured. The whole point of an independent measurement is that it was taken independently, and the difference between the two is the subject of measured and docketed quantity. A copied number destroys the only check anybody had.
• A photograph with no note of where and when. An unlabelled photograph of reinforcement is a photograph of reinforcement somewhere. It answers nothing and it can be answered back with another photograph.

An observation is a record, a conclusion is not#

This is the distinction underneath everything above.

The joint was cast at 3 p.m. and the previous pour was completed the previous evening is an observation. The cold joint is the contractor's fault is a conclusion. The first cannot be attacked. The second invites somebody to attack it, and once they do, the observation buried inside it gets attacked along with it.

The engineer's advantage is that they were there. That advantage is spent the moment they start writing findings instead of facts. A conclusion can be reached later by anyone holding good observations. An observation cannot be reconstructed later by anyone at all.

Where a conclusion genuinely has to be recorded — a decision was taken, work was stopped — write it as what it is, with its author, and keep it in a different sentence from the facts that led to it.

Record it at the moment, not in the evening#

The evening write-up is where accuracy dies. By six o'clock the sequence has collapsed, the two loads have merged into one, and the time an instruction was given has become "in the afternoon".

Record at the moment. Whatever the medium, the entry is worth more the sooner it is made, and a rough entry made at the time beats a tidy one made at eight. If the practical thing at that moment is to speak rather than write, speak — the argument for that is in the voice note is the report. The tidy version can be assembled afterwards into the daily progress report, and it will be assembled out of something real.

A photograph with a note beats a note. The note gives the photograph its where and when; the photograph gives the note something that cannot be rewritten. Neither is worth much alone, which is the argument in a site photograph is a record.

The record he already makes#

There is a version of all this that engineers do without being asked, and most software never sees it. He sends a voice note — hands dusty, screen in the sun, one hand on a ladder. Speech is the only input available, and it usually carries more than the form would have collected.

We treated those as a labelled blob nobody opened for far too long. Transcribing them was the easy half. The half that mattered was deciding that the words afterwards take the same path a typed message takes, rather than a parallel one, because a parallel path is a second implementation of every rule and second implementations drift. That account is the voice note is the report.

If an office wants an engineer to record more, the honest move is to accept the medium he already uses and do the structuring at the desk, where somebody has a keyboard and a moment.

Your own copy is not the office's copy#

The office copy exists to run the project. It is edited, summarised, merged into other documents, and eventually archived by somebody with different priorities.

The engineer's copy exists for one purpose: to say what this person saw, on this day, in their own hand. It should be complete, dated, and kept where a change of employer, a change of software or a change of mood at head office cannot reach it. Nobody is being accused of anything by that. Records get lost innocently far more often than they get lost deliberately, and the reasoning is set out in keep your own copy.

When the two copies disagree, the one written at the site on the day is the one that persuades people.

The short version#

Record what happened, where, in what quantity, and on whose instruction. Record what was covered up and what departed from the drawing, with names against both.

Do not record opinions, guesses dressed as measurements, docketed figures dressed as measured ones, or photographs with no place and no date.

An observation is a record. A conclusion is not. Keep them apart, write at the moment, and keep your own copy.

The scramble is not caused by month-end. Month-end only reveals it. What is actually being done in those four days is a month of matching that was not done as it happened.

What must be true before the books close#

Closing a period is a claim. The claim is that the figures now describe everything that occurred and nothing that did not. That claim rests on a short list.

• Every bill received is either booked or on a stated hold. A hold is fine. A hold with no reason written against it is a bill that has been lost politely.
• Every goods receipt is matched or flagged. Material that arrived and has no bill against it is a liability whether or not anybody has typed it, and the method for getting there is in reconciling a vendor bill.
• Site stock has been counted and reconciled. Opening, plus received, less issued, equals closing — and the counted figure agrees with it, or the difference has a reason. The mechanics are in stock reconciliation.
• The bank is reconciled. Every line on the statement is identified against something in the books, not merely totalled.
• Advances outstanding have been aged. How much is out, to whom, since when, and against what.
• Retention balances agree per contract. Not in total. Per contract, because that is the only level at which retention money is ever released or argued about.
• Inter-entity balances agree in both directions. What one company shows as receivable, the other shows as payable, at the same figure.

And underneath all of it: every accrual has a basis somebody can explain. An accrual whose only justification is that a similar number was accrued last month is not an estimate, it is an inheritance.

The failures that make it a scramble#

Each of these is ordinary. Each of them is also predictable, which is the point.

The bill that arrives on the 2nd for work done in the previous month. The work happened, the period is being closed, and the document is in somebody's bag. This is the single most common cause of a month that has to be reopened.

The site that submits its stock statement late, every month. Not occasionally. The same site, the same delay, and the accounts desk plans around it instead of fixing it.

A payment made from the wrong entity's account. Convenient at the time, because that account had the balance. Now two sets of books are wrong, the inter-entity balances will not agree, and somebody must decide whether it was a loan, a reimbursement or an error. The general shape of that mess is covered in one builder, many companies.

A receipt with a reference nobody can match to a buyer. Money has arrived. It belongs to someone. Until it is identified it sits in a suspense line that grows quietly all year, and the identification only gets harder — the method is matching a bank line.

A bill held for a query that nobody chased. The query was legitimate on the day it was raised. Then it had no owner and no date, and now the vendor is calling about an invoice your books do not show at all.

The adjusting entry made to force a total to agree. The most damaging one, because it works. The books close, the difference disappears, and the cause is still there, producing the same difference next month against a starting position that no longer means anything.

Why the pile forms#

A hold is a legitimate state. A pile is not.

The difference is that a state has an owner and a date. Held pending rate confirmation from purchase, with the buyer who placed the order, since the day it was raised is a state — it can be listed, chased and cleared. Query written on a sticky note on top of a stack of bills is a pile, and a pile is only ever worked when somebody panics about it.

The same distinction applies to unmatched receipts, unreconciled site stock and open advances. Every one of them is fine as a tracked exception and poisonous as an undifferentiated heap. The heap is what makes the last four days feel like an emergency, because the heap is where all the surprises were being stored.

What makes the scramble smaller#

Match daily rather than monthly. The work is the same volume either way. Done daily, a mismatch is investigated while the storekeeper still remembers the lorry. Done monthly, the same mismatch is a research project. Nothing else on this list saves as much time.

Give every hold an owner and a date. Then a hold is a queue with a length, and a queue with a length can be reported on, chased and reduced. A hold without those is indistinguishable from a loss.

Close the previous period rather than leaving it open. An open period is a temptation. Entries drift backwards into it because backwards is easier than raising an adjustment, and after a few months nobody can say which figures are settled and which are still moving. A closed period forces the late bill to be handled as what it is — a known item, in a named month, with a reason — instead of being quietly absorbed.

Fix the recurring late submitter instead of planning around them. A site that is late every month is not an accident. It is a process that has no deadline it believes in, and it will still be late in a year.

The short version#

Month-end is not a task. It is an inspection of whether the month's matching was done, and it feels like a scramble precisely when it was not.

Before you close, know that every bill is booked or held with a reason, every receipt is matched or flagged, stock and bank are reconciled, advances are aged, retention agrees per contract, inter-entity balances agree both ways, and every accrual has a basis.

Then do the matching daily, make every hold a state with an owner and a date, and close the period behind you. The last four days get shorter every month you do it.

Most contractors who lose money on a job did not quote the wrong number. They quoted a number that was right for a set of conditions nobody wrote down, and then the conditions changed.

This is the structure of a rate from the contractor's side, and the conditions that have to travel with it.

What is actually inside a rate#

Build it in layers. Each layer is a real cost that somebody pays, and if it is not in the rate, it is being paid out of the profit.

• Material, with wastage. Not the quantity in the drawing. The quantity you will buy, which is larger, and by how much depends on the item, the handling and the site — the ways that gap opens are in wastage on site.
• Labour, with productivity. A gang's output per day in these conditions, not in ideal conditions. Height, access, congestion and the weather all move it.
• Plant, including its idle time. A machine on hire is paid for on the days it works and on the days a front was not ready.
• Transport and lifting. Getting material to the site is one cost. Getting it to the twelfth floor is a different one, and it is the one that gets left out.
• Scaffolding and shuttering, with repetitions. These are bought once and used many times. The number of repetitions you assume is the single most sensitive assumption in most rates, and it is usually optimistic.
• Consumables and supervision. Small individually, never small in total.
• Overheads and finance. Site establishment, head-office share, and the cost of money for the period between spending it and being paid.

Then retention, which is your money held for a long period after the work is done, and profit, which is what is left if every line above was honest. The retention mechanics are worth knowing precisely before you price them: retention money.

The two everybody forgets#

The cost of money while the bill is outstanding. You buy material, pay labour weekly, submit a bill, wait for measurement, wait for certification, wait for payment, and then wait longer for the retained portion. That gap is funded by somebody, and if it is not funded by the rate it is funded by your overdraft or by your suppliers' patience. A rate that would be profitable at immediate payment can be loss-making at a long cycle, at exactly the same number. Price the cycle, not just the work.

The cost of an item's own quality control and rectification. Testing, sampling, the inspection that fails, the patch that has to be cut out and redone. Every trade has a rectification rate that the people who do it know and never write down. It is not a contingency. It is a normal, recurring cost of producing acceptable work, and it belongs in the rate the way wastage does.

The conditions attached to a rate#

A rate without conditions is an open-ended promise. Five things should travel with every quoted rate, in writing, on the same page as the number.

1. What it excludes. Named, not implied. Scaffolding, lifting, dewatering, cutting and making good, final cleaning, testing — each is either in or out, and "not mentioned" always resolves in the other party's favour.
2. What it assumes about access and continuity. A clear front, handed over in a stated sequence, with continuous work. A rate priced for a continuous run and executed in interrupted patches is a different rate.
3. How long it stands. A validity period, after which it is re-quotable. Without one, a rate quoted at tender is still being applied to work executed years later.
4. What happens if quantities move. A stated variation of quantity clause: beyond some agreed departure from the tendered quantity, the rate is open to review. Both directions, because a quantity that collapses hurts as much as one that multiplies.
5. What happens if the specification changes. A different brand, a different grade, a different finish standard is a different rate, and saying so at quoting time is far cheaper than saying it later.

The traps#

A rate quoted in one unit and measured in another. Per running metre quoted, per square metre measured. Per tonne quoted, per quintal measured. This is the quietest and most expensive error available, because both documents look completely ordinary — see the unit of measure.

A lump-sum item with open-ended scope. "Miscellaneous steel work" or "finishing as required" is not an item, it is an invitation. If the scope cannot be described, it cannot be priced, and the party who wrote the ambiguity is not the party who will pay for it.

A low rate accepted because the quantity is small. Somebody shaves an item nobody expects to matter. Then the design develops, and the quantity of that one item multiplies. Loss per unit is unchanged; loss in total is now enormous. Read the schedule as a set of exposures, not a set of prices — the habit is described in reading a bill of quantities.

Idle time when a front is not ready. Your gang is at the site, your plant is on hire, and the front has not been handed over. Somebody pays for that day. Unless the work order says who, it is you — which is one of several reasons why what a work order should say matters more than the rate printed on it.

A rate accepted verbally and revised in a message. The original rate is in the order; the revision is in a WhatsApp thread. At final account, only one of the two is a document.

The short version#

A rate is material with wastage, labour with productivity, plant with its idle time, transport, lifting, shuttering across its repetitions, consumables, supervision, overheads, finance and profit.

The two most commonly missing pieces are the cost of money while you wait to be paid, and the ordinary cost of putting your own defective work right.

Then attach the conditions: exclusions, assumptions about access and continuity, validity, what happens when quantities move, and what happens when the specification changes. The number is the easy half. The conditions are what make it a rate you can still live with in the final year of the job.

What happens next in most offices is a phone call in which two totals are read out at each other. That call never resolves anything, because a total is a sum of many events and no two people can subtract sums in their heads.

The rule is short. Never reconcile totals. Reconcile events.

The method#

Four steps, in order. The order matters more than the effort.

1. Agree a cut-off date first. Before a single document is compared. Without it, half the differences you find are just the two sides looking at different windows, and you will spend an afternoon discovering that.
2. List every document each side holds up to that date. Bills, payments, credit notes, debit notes, adjustments. Both lists, laid side by side, with dates and references. Not summaries. Documents.
3. Tick what matches, and isolate what does not. Most lines match. The reconciliation is only ever about the residue.
4. Classify each remaining difference by cause. One cause per item, from a short fixed list. This is the step that turns an argument into a worklist, because each cause has a different owner and a different fix.

Do not debate the items while classifying them. Classify all of them first. An item argued in isolation takes twenty minutes; the same item, sitting in a group of six with the same cause, resolves in two.

The causes#

There are not many, and nearly every difference is one of them.

• Timing. The document exists on both sides but falls in different months, or a payment is genuinely in transit. Nothing is wrong. It clears itself next period.
• A document one side never received. A bill posted and lost, an invoice emailed to somebody who left. One ledger has an event the other has never seen.
• A deduction one side made and did not communicate. The largest category, and the subject of the next section.
• A payment applied to a different bill. The money agrees; the allocation does not. Your ledger shows one invoice settled, theirs shows a different one settled and the first still open.
• A debit or credit note raised silently. Issued, posted internally, never sent. It moves your balance and nothing on their side moves with it.
• A rate or quantity difference on a single line. The bill was booked at the rate that was ordered, or at the rate that was invoiced, and those were not the same rate.
• Rounding, or a unit difference. Small and constant, or large and structural. Both look identical in a total.

Anything that is none of the above is a genuine error, and there are always fewer of those than either side expects.

Deductions are the biggest single cause#

Because of what a deduction is. It is a decision made by one party, taken unilaterally, and communicated as a smaller number.

The payer knows exactly why the figure was reduced — short supply, damage, a rate correction, recovery of an advance, a set-off against another account, a quality disallowance. The payee receives a payment that is less than the bill and no explanation, and has to guess. So they post the receipt against the bill, leave a balance open, and chase it.

Both ledgers are now internally consistent and mutually contradictory, and they will stay that way for months. A year of this produces a confirmation that is out by an amount neither side can decompose. The conduct that prevents it is set out in paying less than agreed, and where the reduction is money owed the other way, the mechanics and consequences are in set-off.

Two practices remove almost all of it.

Every deduction carries a reason and a reference on the advice. Not in the accounting system, where only your side can read it. On the document the other party receives, against the specific bill it reduces.

Every payment states which bills it settles. In full or in part, named by number. An unallocated payment is a difference waiting to be born, and it becomes the same problem on the receiving side that an unidentifiable credit in the bank statement is on yours — the identification work described in matching a bank line.

Do both, and the confirmation exercise stops being a negotiation. It becomes a tick-off.

What to do with what will not resolve#

Some items survive the classification. A deduction the other side disputes. A note one party insists was never received. A rate difference where each side holds a document supporting its own figure.

Do not net them into the balance. Netting a disputed item makes the total agree and destroys the record of the disagreement, and in six months nobody will be able to say what was conceded, by whom, or in exchange for what.

Record disputed items as disputed, on both sides, individually, with the amount, the reason and the date the dispute was raised. The agreed balance is then stated as the reconciled figure plus a listed set of open items. That is an honest confirmation, and it is a far stronger position than a clean number that quietly absorbed a concession.

Some of those items will eventually be conceded or abandoned. When that happens it is a decision with an author and a date, taken deliberately — the discipline in writing off money — not a figure that softened while nobody was watching.

Reconciling often also shortens the collection cycle, because most delayed payments are not refusals. They are documents nobody could match, which is half the ground covered in getting paid on time.

What we changed on our own side#

Deductions were the cause we could design against, so we did.

Recording a stage payment below the agreed figure now asks why less? before it will accept the number. The shortfall and the reason sit on the stage row itself, not in a comment somebody may or may not read. And when the last stage of a schedule is settled, the order's total corrects itself to what the stages actually recorded. We swept the same rule backwards over schedules that had already closed.

It is a small prompt and it was not popular for a week. What it buys is that six months later, the gap between what was agreed and what was paid has a sentence attached to it, written by the person who decided, on the day they decided. That is the whole of what a reconciliation is trying to recover, and it is far cheaper to capture than to reconstruct.

The short version#

Agree the cut-off, list the documents, tick what matches, and classify every residual difference by cause before arguing about any of them.

Most differences are timing, a missing document, an unexplained deduction, a misapplied payment, a silent note, or a single line's rate. Deductions dominate, because they are decisions communicated as a smaller number.

Put a reason and a reference on every deduction, name the bills on every payment, and record what cannot be resolved as an open dispute rather than folding it into the balance.

It was a completely accurate observation and a completely wrong diagnosis, and it was made twice in a single day, about two faults that had nothing to do with each other. Nothing was ever wrong with that link.

The first one: a sheet nobody could see#

A greeting panel mounted the moment it had something to show, while it was still marked as not yet visible. In that state it painted at zero opacity, covered the entire window, sat above everything else on the page, and still accepted every click.

It was meant to be switched to visible by an animation frame. Animation frames do not fire while a browser tab is in the background. This is an application people leave open in a background tab for hours at a stretch, so for those people the frame simply never came, and an invisible sheet stayed spread across the whole window taking every tap.

The page looked entirely normal. Nothing on it responded, anywhere, until it was reloaded. Settings looked like the culprit because the profile icon happens to be the first thing most people try.

Two fixes, and the order they went in matters more than either of them.

First, the general one: an overlay that cannot be seen may not take a click. That is now true everywhere in the application, regardless of what else goes wrong around it, and regardless of why some future overlay ends up invisible.

Only second, the specific one: the greeting no longer waits on a frame that is never coming.

Doing the specific fix alone would have made the symptom disappear and left the shape exactly where it was. The next transparent overlay would be written in a different file, later, by somebody who had never heard this story, and it would produce exactly the same confusion.

The second one: two handlers, and the blind one won#

Later the same day, the same words from the same person. This time it really was the menus.

Menus in this application are rendered into the end of the document rather than in place, so that the header cannot clip them. The component that owns them closes on an outside click, correctly, by checking whether the click landed inside the panel it actually painted.

But four of those menus had also kept an older handler from before they were moved, one that checked whether the click landed inside the component's own wrapper. Once the menu was being rendered elsewhere, its items were no longer inside that wrapper. So a click on a menu item looked to the old handler like a click on the outside world, and it closed the menu on the press, a beat before the click could reach the link underneath.

Two handlers watching for the same event. One of them blind to where the menu now lived. The blind one won the race.

The fix was deletion. The four components stopped keeping their own handler, and the one place that logic belongs does it for all of them.

Why this is worth writing down#

A symptom is a location, not a cause. It tells you where somebody was standing when the work stopped, which is genuinely useful, and it tells you almost nothing about why.

More usefully: the same symptom can have several different causes queued up behind each other. Fix the first, ask "is it working now?", and the honest answer from the person now standing in front of the second one is no. This reads, to everybody involved, as the fix having failed. It is a bad moment. It is also the ordinary state of affairs in any system old enough to have been changed by more than one person, and expecting it makes it much less alarming.

The useful discipline is to separate what was observed from what was concluded, even when the person reporting it is certain, and especially when they are right about the observation. Two things were true at once here: the link was not working, and nothing was wrong with the link.

The check that was wrong about itself#

One more piece, because it is the part we would most like to have skipped.

The automated check written to stop the invisible overlay coming back was wrong on its first attempt. The long comment explaining the fix had been placed between the two things the check needed to compare, which pushed one of them outside the window it was looking at. So the check passed. It passed with the bug sitting directly in front of it, and it would have gone on passing for as long as anyone cared to trust it.

That was only found because the bug was deliberately put back, to watch the check go red. It did not. The check now strips comments before it looks, and it was re-tested the same way.

A test you have never seen fail is a test you are trusting on its own word. It takes about a minute to break the thing on purpose and confirm that something notices. Almost nobody does it, which is why so many green suites are green for reasons unrelated to the code being correct.

The shape#

The people reporting problems are describing where they were standing. That is their job, and it is a real contribution. Turning that into a cause is ours, and the work is mostly resisting the first plausible explanation for long enough to check whether the thing named in the complaint was ever involved at all.

The check that passed with the bug in front of it has a longer treatment in a test that describes the code will defend a bug, and the habit of explaining a refusal rather than simply making one is in the app should tell you why.

This is about the structure of the arrangement, not the law around it. Statutory obligations attaching to contract labour are real, they differ by where and how you operate, and they change. Verify the version in force with your own advisor before you act on any of it. What follows is only about keeping the hisaab straight between two parties.

Two bases, and most arrangements are quietly both#

Attendance. So many workers, so many days, at a day rate per category. Simple to administer, and it pays for presence rather than output.

Measured work. A rate per unit of work completed, measured jointly. It pays for output, and it needs a measurement everyone accepts.

Almost every real arrangement is both, and almost nobody says so. The headline is a piece rate, but the gang was also on site for three days when no front was available and something has to be paid for that. Or the headline is a day rate, but everyone knows that a certain output is expected and a shortfall will be argued about at the end of the month.

Write down which basis governs, and — this is the part that is always missing — write down what happens in the cases the basis does not cover. Idle days when a front is not ready. Work done and then damaged by another trade. A partial month. If those are undecided at the start, they are decided at settlement, by whoever is holding the money.

The muster, and what makes one credible#

The root of most labour disputes is an attendance record kept by the contractor's own supervisor and never independently seen. It is written by the party being paid, for the party paying, and nobody else ever looks at it. Whatever it says is what gets paid, and both sides know it can be wrong in either direction.

A credible muster has four properties.

• Recorded at the site. Not compiled at a room somewhere from a phone call. At the gate, or at the workface.
• Recorded at the time. Morning, when people arrive, not reconstructed in the evening from memory and a headcount.
• Recorded by a person who was there. Someone who could see the people they were marking present.
• Able to tell one worker from another. A count is not attendance. A count can be inflated by one and nobody can prove anything. Identity is what makes a muster evidence.

The site's copy and the contractor's copy should be made from the same act, not from two separate acts that are later compared. Where the site has no network at the gate, the capture still has to happen at the gate and reach the office afterwards, which is the whole argument in attendance without signal.

The payment mechanics#

Four things move money between the headline figure and what is actually handed over, and each has its own history.

• Advance taken mid-month. Almost universal, because gangs are paid weekly and bills are settled monthly. It is a loan, it must be recovered, and it needs a running balance — the same discipline as a mobilisation advance at a larger scale.
• Deduction for material issued. Cement, binding wire, consumables, sometimes tools. The contractor's account is debited at an agreed rate. This only works if the issues were recorded when they left the store, as in running a site store.
• Deduction for rectification. Work redone by others at the contractor's cost. Legitimate, and the one most often applied without telling anybody what it was for.
• Retention or a held amount. Some portion kept back until the work is complete or a defect period passes.

And the thing nobody keeps: a running balance. Bills raised, payments made, advances given, advances recovered, deductions applied, balance carried forward. Kept monthly, it is a page. Kept nowhere, it becomes the final settlement argument.

Where it goes wrong#

A name on the muster nobody can identify. Present for months, paid for months, and no one at the site can point to the person. Either the record is inflated or a real worker is unidentified, and neither is discoverable afterwards.

A worker paid by both the contractor and the site. Somebody was pulled onto a departmental job for a week, marked present on both records, and paid twice. Common where labour moves between gangs.

An advance given in cash with no acknowledgment. The commonest single cause of a settlement that cannot be closed. The site is certain it was given; the contractor is certain it was less, or was against something else. There is nothing to consult.

A measurement agreed verbally at site. Two people looked at the work, agreed a figure, and neither wrote it down with both names against it. Six weeks later they remember different figures, honestly.

The final settlement where neither side's arithmetic agrees. The predictable consequence of the four above. Months of small undocumented adjustments accumulate, and at the end of a job the two totals differ by an amount neither party can decompose. It is the same disease, at a smaller scale, as when your ledger and theirs disagree, and it is settled the same way — by events, not totals.

What helps#

Capture attendance where the person is. At the gate or the workface, at the time, with something that distinguishes one worker from another. Every other improvement depends on this one.

Keep an issued-material register the contractor signs. Signed at issue, not agreed at settlement. An unsigned issue record is your word against theirs, and at settlement it is worth nothing.

Hand over a running statement every month. Bills, payments, advances, recoveries, deductions with reasons, and the balance. Given monthly, a disagreement surfaces while both parties still remember the week in question. Deferred to the end of the job, the same disagreement is unresolvable and usually ends with somebody being cheated.

Give the contractor a copy of everything they signed. A party who holds no records has no way to check yours, and a contractor who cannot check becomes a contractor who assumes the worst — which is the general case for keeping your own copy on both sides of any arrangement.

The short version#

Decide whether you are paying for attendance or for measured work, and write down what happens in the cases that basis does not cover.

Make the muster credible: at the site, at the time, by someone who was there, with workers distinguishable from one another. Record advances and material issues at the moment they happen, with a signature.

Then hand over a running statement every month. Almost every labour settlement that ends badly ended badly because the arithmetic was attempted once, at the end, from memory.

It shipped as one line of styling on the page body, and that line inherits into everything inside it. So the application capitalised its labels, which was the idea, and it also capitalised task titles, descriptions, comments people had typed themselves, names, error messages and empty states, which was not.

For about a week it looked deliberate. Then it just looked loud.

What it cost#

Capitals work as emphasis only while most of the screen is not capitalised. Emphasis is a difference, not a property. Spend it on everything and there is none left over for the four labels that genuinely needed it, and the screen arrives at a strange place: every element is shouting and nothing stands out.

The second cost is not a matter of taste. We read words by their shape. The tall letters and the ones that hang below the line give every word an outline your eye recognises before you have finished looking at it. Capitals are all the same height with flat sides, so the outlines collapse into rectangles and a capitalised sentence is read closer to letter by letter. That is measurably slower, and it is worst in bad conditions: on a phone, outdoors, in sunlight, which is where a great deal of this particular application is used.

How it was noticed, which is the interesting part#

Not by a complaint. Nobody in the building said "the type is tiring". People almost never say that, because nobody experiences reading as a task they could have an opinion about.

It was noticed by comparison. Two screens were put side by side, built in the same palette, and one of them looked expensive and the other did not. The difference was assumed to be the typeface. It was not the typeface. It was case.

That is the usual route for this class of problem. It does not arrive as a report. It arrives as a vague preference for one thing over another, and the work is turning the preference into a sentence somebody can act on.

Writing the rule down as data#

The repair could have been a comment in the code saying what capitals are for. A comment agrees with itself for ever and stops nothing.

Instead there are now two lists: what capitals are for, and what may never be capitalised. The second list is the one that matters — a person's name, a proper noun, anything a human being typed. Written as data rather than prose, a checker can execute it and refuse a change that breaks it. Written as a paragraph, it would have survived exactly as long as the memory of the argument that produced it.

Then the blanket rules were separated by what they actually govern:

• A chip and a field label keep their capitals. Both are short names for a slot, not sentences.
• A button lost them. A button's text is a verb somebody reads and then acts on.
• Navigation labels lost them, which is why the menu had been shouting the name of every page even though those names were written in ordinary case in the code.
• A section heading lost them, because a heading is a phrase.

The catch that nearly shipped a regression#

Of the application's table header cells, 129 out of 138 carried no case rule of their own. For as long as the blanket rule existed they never needed one. So deleting the blanket would have quietly un-capitalised every column heading in the application, which the newly written rule says should be capitalised: a column heading is a short name for a slot, the clearest case there is.

This is worth generalising. A blanket rule does not only apply a thing. It hides which places were depending on it. Every site that stopped declaring its own intention because the blanket was covering it becomes invisible, and stays invisible right up until the blanket comes off. Removing one is a survey, not a deletion, and the survey is the whole job.

Where we deliberately did nothing#

The screens at the gate were left exactly as they were. Their signage is pictograms, very large tabular numerals and Devanagari, none of which capitalisation touches at all. They were built to be usable by somebody who reads neither English nor the interface language, so they never leaned on capitals in the first place and had nothing to lose.

It is worth checking for that before a sweep. The screens that need protecting from a change are rarely the ones you expect, and some of them turn out to have been immune the whole time, for reasons that were good ones when they were built.

The shape#

The instruction was right. The implementation was one line too broad, and the whole cost sat in the scope rather than the intent.

The wider lesson about blanket rules — that removing one is a survey rather than a deletion — is in a default is a decision somebody made once. And the gate screens that were immune to all of this are the subject of a gate register somebody will actually keep.

That is a very common way for a small change to become a problem nobody can name. Everyone agrees with what was asked for. Everyone can see the result is somehow worse. Because the request was granted, there is nothing obvious to complain about, so nobody does, and the screen stays tiring for a year.

There was no way to undo it. The number stayed wrong, and the correction happened on paper, in a note, and in the head of the one person who remembered which entry was the bad one.

The strange part is that the code to undo it already existed. It had been written. It had no callers at all. No button, no menu item, no route: a complete, plausible, entirely unreachable function.

This is one of the commonest things we find#

It is not a curiosity. On the same system, two buttons — send this document for signature, and open it in the document editor — had never once appeared for anybody, on any screen, in the whole life of the feature. Both were gated on a flag meaning "this file can be edited as text", which is false for every PDF there has ever been. The feature worked. Nobody could reach it.

Elsewhere, text had been machine-read out of well over a thousand photographs sent from site, and stored, and nothing had ever looked at it. The check that should have used it read only the caption somebody typed, and site photographs usually have no caption, because the delivery slip in the picture already says everything.

Built is not the same as reachable. Reachable is the only one a person experiences.

Wiring it up was not safe#

This was the lesson we did not expect, and it is the more useful one.

Code that has never run has never been wrong out loud. It has been reviewed, probably, and it reads correctly, and it has never once met a real store, a real lorry or a real person in a hurry. Six faults had to be fixed before that undo could be given a button. Some of them, in shape:

• It marked the original entry as cancelled, and one of the readers that counts stock never checked that mark. A cancelled receipt would have gone on counting for ever, and the balance would have been wrong in a new way.
• It never asked whether the stock had since gone out again. Cancelling a receipt after most of it had been issued would have driven the balance below zero, silently, which is not a state a store can be in.
• Its permission check asked only whether you were an administrator, so anybody whose name was on a row could cancel that row.
• It could reach through the store's door and cancel an entry that the gate had written, leaving the gate's own register saying the lorry arrived and the entry impossible to put back.
• The reason for the cancellation never reached the audit trail, because the trail reads the reason from the record's new state and no reason was ever handed to it. Every cancellation would have been recorded as having happened for no stated reason.

None of those is a careless mistake. Each is the kind of thing you discover the first time the code meets the world, and this code never had.

What it does now#

A cancellation writes two halves in one movement: the original marked cancelled, and a reversing correction of the opposite sign which is born already cancelled itself.

That shape is deliberate. A reader that filters out cancelled rows sees neither half. A reader that forgets to filter sees both, and both add to zero. The answer is correct under either reading, which is what you want when you cannot personally audit every piece of code that will ever count your stock. It is also keyed so that a second reversal of the same entry is impossible.

Before it acts it states the effect in numbers: the store reads this much of this material, cancelling this entry leaves that much. And it requires a reason, which now actually arrives in the record.

Why nobody asked for the button#

Because there was a workaround, and the workaround worked.

Somebody knew how to make the number look right again. It took a few minutes, it involved a second entry and a note, and it was taught to the next person who needed it. Within a few months it was simply how a wrong receipt gets fixed here. The gap had not closed. It had been staffed.

Nobody files a request for something they have already learned to live without. That is not a failure of the people; it is what competent people do with an obstacle. They route around it, and the routing becomes invisible, including to them.

Two questions worth asking of your own tools#

The first: what has been built here that nothing calls? Not as an audit exercise — as a search for things somebody once thought were needed, and were, and never arrived. Half-finished work does not announce itself, because from the outside it looks exactly like work that was never started.

The second, and it is better: what does everybody in this room already know how to work around? Ask it out loud, in a meeting, and wait through the pause. The answers do not come as complaints. They come as instructions, delivered helpfully, in the tone of someone explaining how a door has to be lifted before it will close.

It is also the most productive question to ask when somebody is leaving a role, for the reasons in what makes a handover fail. And the reversal described above is a worked example of a rule we hold everywhere: correct by adding, never by overwriting.

They were not ignoring it, and they had not missed a message. The message had arrived exactly as the system intended, and the way the system intended was wrong.

What the machine actually did#

The signature request went out carrying a generic type: question. Types are mapped onto rows in a grid, and question had been mapped, sensibly enough, onto the row for comments. The comment row's default delivery is a bulletin: held back until the next scheduled broadcast, three a day, ringing nothing, arriving as one line among a dozen others that also did not need doing right now.

So a document that was holding up a payment was delivered as chatter.

Every component in that chain did its job. The request was raised correctly. It was classified into a real category. That category was routed by a rule somebody had written down on purpose. Nothing failed. The design had simply never been asked what a signature request is, so it answered a different question and answered it well.

The distinction we ended up writing down#

The instinct, when this surfaces, is to reach for importance: mark it urgent, give it a red badge, put it higher in the list. That is the wrong axis, because everybody's own work is important and a scale where everything is at the top is not a scale.

The useful question is not how important a message is. It is what it asks the reader to do. There are only three answers.

• Nothing. You should know this happened. Read it whenever.
• Later. Look at this next time you are looking at things.
• Now. Somebody is standing still until you act.

A signature request is always the third. It is not information about work; it is a request for a specific person's hand, and until that hand moves, a document, a payment and usually another human being are all stopped. It now has its own type, sitting on the row for things awaiting approval, and it says plainly that it asks for an act. It arrives on its own and it rings. It also says which page of the document the signature goes on, because "sign this" without "here" is still a small piece of homework.

Why nobody reported it#

This is the part that makes it our kind of problem.

The person who had to sign did not know there was anything to report. From where they stood, nothing had happened. The person who sent it assumed it had landed, because sending it had produced no error and the software said it had gone. Both of them held a completely consistent picture of the day, and the two pictures did not overlap at the point where the work was stuck.

That is the most durable kind of gap. It has no owner, because nobody experiences it as a gap. It gets discovered the way this one did: somebody asks why a thing has not moved, and the answer turns out to be that nobody was ever told to move it.

Defaults are decisions#

Every routing table has a default, and a default is a decision made once, in the abstract, by somebody who was not thinking about your document. It then applies to every message that will ever be classified into that row, for years, without being revisited, because nothing about it ever looks like a choice again. It looks like the way things are.

That is why the fix was not to make the alert louder. Loudness is a resource with a fixed supply. An application that rings for everything is an application people mute, and a muted application delivers nothing at all. Quiet is a feature, and the bulletin row is doing real work for the messages that genuinely belong to it.

The fix was to stop lying about what the message wanted. Once a request says "this asks somebody to act", the routing follows on its own and no one has to argue about priority.

The general shape#

If something in your work regularly waits on a person who did not know they were being waited on, the problem is unlikely to be that person. Look at how the request was categorised on its way to them, and ask what else shares that category. You will usually find one bucket carrying two kinds of message: the kind that is nice to know, and the kind that is holding up a room. They cannot share a delivery rule, however tidy it looks in the table.

The general form of the routing rule is set out in an alert that rings for everything, and the wider habit of never revisiting a setting made once is a default is a decision somebody made once.

Everything else in this class is the same. We wrote about the gap you stopped noticing before we had this example. This is what one looks like from the inside.

And a queue inside our own software kept asking for it to be paid again.

Why it happened#

The record of this is paid was a single date stamp on the task. Paying in stages does not write that stamp, and that is not a bug: when a payment has a schedule, the stages are the payment record. There is nothing missing.

So any screen that asked "is the paid date set?" was blind to every rupee that had ever moved in instalments. One screen asking the wrong question is an ordinary defect. What we actually found was the same question being asked all over the application, in place after place, each in its own words, each written by somebody who reasonably assumed the stamp meant what it looked like it meant.

Four of them were queues and counters: the list of payments cleared to pay, the list waiting for a signature, the number in the sidebar, and the sweep that puts a decision back in front of somebody who has already made it.

Five more were found afterwards, and one of them was expensive.

The one that cost people time#

A material line on an order paid in stages sat at "waiting on payment" forever. That stage of the journey has a chaser attached to it, and the chaser rings Finance every three days.

So Finance was being reminded, every three days, about money that had already left the account.

Nobody reported it. That is the part worth sitting with. It is not that somebody noticed and was ignored. It is that a recurring reminder which is occasionally wrong teaches you to skim the whole class of reminder, and once you skim it, the one that matters costs the same as the ones that do not. The chaser was not merely useless here. It was quietly spending the credibility of every other chaser in the building.

The one that could have stopped a lorry#

The same stale question was being asked at the gate. The guard's list of loads to expect refuses any line whose money has not settled, which is sensible. A load paid to the last rupee in stages carried no stamp, so it never reached the list, and a lorry that had been fully paid for arrived at the barrier unannounced.

That is the exact event the screen exists to prevent. It had been prevented in every case except the ones paid in the way the biggest orders are paid.

The fix is not one fix per screen#

Writing the correct condition into each of those places would have produced a copy of a rule per screen, which is the same problem again with a longer fuse on it. There is now one function that answers "has the money for this actually settled?", living in the file that owns payment schedules, with a mirror of it in the database query language beside it so the two cannot drift apart. Every surface asks it. None of them owns a second opinion.

One detail from the repair is worth stating plainly, because it is the least comfortable thing we found.

One of our own regression tests was holding the bug in place. The test that guarded the "this is paid, close it?" prompt was anchored on the stale date stamp, because at the time it was written that was what the code said. It passed happily while the prompt failed to appear on exactly the orders it was built for. A test that describes the code rather than the rule will defend a defect as loyally as it defends a feature, and it will do it while reporting green.

The shape#

Any fact your work depends on that is computed in more than one place will eventually disagree with itself. It will not disagree loudly. Nothing crashes. Two screens simply say different things about the same order, on the same morning, and each person takes the answer from whichever screen they happen to be standing in front of.

It survives because everybody's own view of it stays consistent. The person in Finance sees an unpaid order and chases. The person who paid it sees a paid order and does not understand the fuss. Neither of them is looking at a contradiction; they are looking at their own screen, which agrees with itself.

If you want to find these in your own tools, do not look for error messages. Look for a fact that several teams each know how to check, and ask each of them to describe the check out loud. The gap is the difference between their answers. It is usually the case nobody enumerated: the part payment, the cancelled order, the one that was settled a different way.

A fact worth trusting has one owner. Everything else asks it.

The same structure, described for anybody running a purchase ledger rather than a codebase, is in why staged payments break accounting systems. The test that was holding this particular bug in place has its own piece: a test that describes the code will defend a bug.

That sounds casual. It is actually the most demanding sourcing method there is, because it means we can only work on problems we are ourselves standing in. We find our problems by living them.

There are three stages, and they are not equal.

Notice — name it out loud#

Noticing is the hard part, and it is hard for a reason that has nothing to do with intelligence. Any problem that survives longer than about a month stops being experienced as a problem. It gets absorbed into the description of the job. Ask somebody what is broken and they will tell you what broke this week; the thing that has been broken for three years does not come up, because it has stopped being an event and become the weather.

So the only reliable move is to say it out loud, in plain words, to another person: this step exists because of nothing. Naming it is what converts a tolerated condition back into a problem, and until that happens no amount of engineering will help, because nobody has agreed there is anything to fix.

The three rules then decide whether it is ours. Is it real, is it big enough to matter, and is it something worth doing regardless of whether it makes money. Most things fail the second rule and that is fine — small annoyances can wait.

Build — the smallest honest fix#

The word carrying the weight is honest, not small.

Small is easy and usually wrong: a shortcut, a button, a script somebody has to remember to run. That is another workaround, and workarounds are what we are here to remove, so shipping one is not a win.

Honest means the fix addresses the actual cause rather than the symptom somebody complained about. Sometimes the honest fix is one field on one screen. Sometimes it is an instrument. What is not allowed is a fix that looks finished while the gap is still there — a page that renders, a demo that completes, a pilot that quietly dies once the person who cared moves on.

The field test is the only test that counts. Not the demo, and not the happy path: a full working day, in the real place, on a bad connection, with the people who will actually use it and none of the people who built it standing nearby. If it cannot survive that, it is not finished, and it does not get called built.

Keep alive — we run what we build#

This is the stage almost everybody skips, and it is the one that makes the other two mean something.

We run what we build. The same people who closed a gap stay responsible for it being closed next month. Nothing gets handed to a maintenance team, declared done, and then slowly rots while the people who understood it move on to more interesting work.

Consequences of that rule, in order of how uncomfortable they are:

• Everything built is a permanent liability, so we build less. The question is never just can we? but are we willing to run this for years?
• Bad decisions come back to their authors. There is no distance between design and consequence, which is the cheapest quality mechanism ever invented.
• Total volume is capped by capacity to keep things alive. That cap is the point, not a limitation.

It also closes the loop, because running something is the single best way to notice the next gap. The people operating an instrument every day are the ones who see the thing it still cannot do. Stage three feeds stage one, which is why the method does not run out of material.

What this method cannot do#

It is worth being clear about the cost. Problems nobody in the group experiences are invisible to us. This method has excellent taste about problems we live with and no opinion at all about problems we do not, which is a genuine blind spot and not a modest one.

The only fix for it is other people describing their own walls. If something in your daily work is broken in a way everybody has stopped complaining about, that is exactly what we want to hear — hello@be-teck.com.

Two of the method's rules have been written up on their own since: the machine proposes, a person decides, which decides what we are willing to let software do unattended, and what an audit trail is actually for, which decides what has to survive after it has done it.

The stack is the problem. Not any one document in it — the fact that a human being has to hold all of them in their head at once and decide whether they agree with each other.

Kshetron rebuilt that stack as one readable surface. It is not a portal that links to other portals. It is five instruments that share the same ground.

Terrex — the flagship interface for the field#

Terrex is the one you stand in a field with. It is the full instrument: the place where land, its records and the work happening on it are held together, built for people who are outdoors, on a phone, and often on a connection that comes and goes.

Terrex sets the standard the other four are measured against, which is why it carries the platform's own green.

Classic — the proven, simpler way in#

Not everyone needs the full instrument, and not every day is a full-instrument day. Classic is the simpler, proven way in: fewer moving parts, less to learn, and the same underlying records.

Keeping Classic alive is a deliberate choice. A new interface that forces everybody through it on day one is not a fix, it is a second problem. Classic is the door that was already open, kept open.

Kaagaz — documents, drafted and signed#

Kaagaz means paper, and that is the joke and the job. It is where a document is drafted, checked, agreed and signed, so that the paper stops being an artefact that lives in somebody's drawer and starts being part of the record.

The gap Kaagaz closes is the one between the deal everyone agreed to and the document that says so. Those two things drift apart constantly, and the drift is where disputes are born. What makes a signed document worth signing is tamper-evidence rather than tamper-proofing.

Tempo — people, work and money, kept in time#

Tempo is the internal instrument: who is working, on what, and what has been paid. Attendance, tasks, approvals, invoices and the money that moves against them.

The name is the whole design brief. Almost nothing in an organisation fails because a fact was unknown. It fails because the fact arrived late — the approval after the payment, the payment after the deadline, the deadline after the excuse. Tempo's job is timing.

BEAi — a closed-world assistant that cites its sources#

BEAi answers questions about the estate's own material, and the two words that matter are closed world. It does not roam. It answers from what it has been given, and it shows you where the answer came from.

An assistant that produces a confident paragraph with no provenance is worse than no assistant, because it manufactures certainty at exactly the moment somebody needs to check. Citation is not a feature bolted on. It is the reason this one was allowed to exist.

Five colours, one family#

Each instrument owns one colour so the family reads at a glance — Terrex green, Classic amber, Kaagaz violet, Tempo pink, BEAi yellow. Look at any screen for half a second and you know which instrument you are in before you have read a single word.

That is not styling. In an estate where a person moves between five tools in a morning, colour is the fastest possible orientation, and getting oriented slowly is itself one of the gaps.

Seeing them#

Each instrument has a public preview: a working-feeling interface with no real data in it. The real thing sits behind a gate, because it holds real records about real people and real land, so preview is the honest word for what is open.

• Terrex
• Classic
• Kaagaz
• Tempo
• BEAi

A longer view from the outside is at kshetron.co.in/about.

That slip is a delivery challan. It is one of the most important documents in construction and one of the least carefully handled, and the reason is that almost everybody treats it as a receipt when it is nothing of the sort.

What is actually written on it#

A delivery challan is the seller's statement of what left their premises. In its ordinary form it carries the date, a serial number, the consignor and the consignee, the vehicle number, a description of the goods, the quantity, and somewhere near the bottom a space for a signature at the other end.

Under the GST rules a delivery challan is the right document for movements where a tax invoice is not — goods sent out for job work, goods sent on approval, a single order delivered in several vehicles, material moved between two of your own premises. In those cases the challan is not a lesser version of an invoice. It is the correct paper for that movement, and the invoice comes later or not at all.

What it proves#

It proves dispatch. Somebody at the other end loaded a stated quantity into a stated vehicle on a stated day and wrote it down.

That is genuinely valuable. It fixes a date, it fixes a vehicle, and it fixes a number that the seller cannot later quietly revise, because you are holding their own copy of it. It cuts both ways, which is why it is worth writing a challan that protects the supplier if you are the one dispatching.

What it does not prove#

It does not prove that the quantity written on it is the quantity that reached your store.

This is the whole point, and it is the part people skip because the paper looks so official. The challan was written at the loading point. Between there and your gate a load can be short, wet, broken, partly delivered somewhere else, or simply counted differently by two people using two methods. A challan signed at your gate proves the driver got a signature. It does not, by itself, prove agreement about quantity.

The document that records what you say arrived is a different document, and it is written by your side. That is the goods receipt note, and keeping the two separate is the foundation everything else in purchase accounting is built on.

Why the difference matters at the gate#

The gate is where a challan is either turned into a record or lost.

If the person at the barrier signs the challan, hands back the top copy and keeps a carbon that goes into a spike file, you have a stack of paper and no data. Six weeks later, when an invoice arrives for a quantity nobody remembers, the only way to check it is to send somebody to the spike file.

If instead the gate writes the challan number, the vehicle number and its own count into a register at the moment the lorry is standing there, the challan becomes checkable. We have written separately about what makes a gate register somebody will actually keep, because the difficulty is never that people do not understand why it matters. It is that the register was designed by somebody who has never held a pen in one hand and a torch in the other.

A challan filed against nothing#

Here is a failure we found in our own software, because it is a good illustration of how this document gets lost even after it has been captured correctly.

Site staff were photographing delivery slips and sending them in. The photographs were being read, the challan details extracted, and each one offered a match against the purchase it belonged to. All of that worked.

But the matcher only ever considered purchases that had not yet been paid. In our own process, payment is required before a lorry is dispatched at all. So by the time material arrived and somebody photographed the slip, the correct purchase was always in the paid state, and therefore was never offered as a candidate. The challan matched nothing. And a challan filed against nothing is displayed on no screen anywhere, which means that from the outside it looks exactly like a challan that was never captured.

Nothing errored. The photographs kept arriving, the reading kept working, and the result kept being invisible. The fix was one sentence long: paid purchases are offered the match too, closed ones still are not.

What to do with one, in order#

1. Count before you sign. The signature is the moment your side commits. Everything after it is an argument.
2. Write your own number down, even when it is the same as theirs. Especially when it is the same as theirs.
3. Keep the challan number. It is the only handle that connects the physical arrival to the paperwork that follows — the receipt note, and later the invoice.
4. Note the vehicle number. Disputes about deliveries are very often disputes about which delivery, and the vehicle is what separates them.
5. Photograph it before it goes into the file. Paper on a construction site has a survival rate nobody would accept from any other record.

Then, when the invoice appears, you have three independent statements of the same event — what was ordered, what was delivered, and what is being charged — and you can hold them against each other. That comparison is three-way matching, and it is the only reliable defence against paying for material that never arrived.

The short version#

A delivery challan is the seller's word about what left. Your goods receipt note is your word about what came. An invoice is the seller's claim about what you owe. Three documents, three authors, one event.

Treat any of them as a substitute for the others and you have quietly agreed to pay for whatever the vendor writes down.

That is the entire definition, and every useful property of a GRN follows from one word in it: own. The challan is the vendor's document. The invoice is the vendor's document. The GRN is yours. It is the only one of the three written by somebody whose interest is in the number being right rather than being high.

What goes on it#

At minimum: the date and time of receipt, who received it, the purchase or work order it belongs to, the vendor, the material, the quantity your side counted, the unit that quantity is in, the vehicle, and the delivery challan number it corresponds to.

Then two fields that are usually missing and matter more than most of the above:

• The condition. Broken bags, wet cement, bent bars, short by three pieces. If there is nowhere to write it, it will be written nowhere.
• Whether it was accepted, rejected or accepted in part. A GRN that can only say "received" cannot describe the most common awkward case, which is a load you take in and argue about afterwards.

Why the vendor's paper cannot do this job#

Consider what happens if you skip the GRN and simply post the challan quantity into stock, which is what a great many organisations do because it is faster.

Your stock now says exactly what the vendor said it should say. The vendor's invoice will also say what the vendor said. So the invoice will agree with your stock perfectly, every time, including on the deliveries that were short. You have built a check that cannot fail, which is the same thing as no check at all.

The GRN exists to introduce a second, independent number into the process. That independence is not paperwork. It is the mechanism.

Where GRNs go wrong#

It is written later, from the challan. Somebody collects the day's slips and enters them in the evening, copying the vendor's quantities. The document now exists and the independence does not. If the GRN is not written at the point and moment of receipt, by the person who counted, it is a transcription, not a receipt.

Nobody records the unit. Twelve of what? Bags, tonnes, running feet, cubic metres, pieces. A store that holds one material in two units will eventually be wrong about it, which is a big enough problem on its own that we wrote about the unit of measure and where it leaks money.

There is no way to correct one. This is the most damaging of the three, because it converts a small error into a permanent one.

The undo that did not exist#

A storekeeper types the wrong quantity into a receipt. It happens the way every typing mistake happens: at the end of a long afternoon, on a phone, with a lorry waiting.

In our own system there was, for a long time, no way to undo it. The number stayed wrong. The correction happened on paper, in a note, and in the memory of the one person who knew which entry was the bad one.

When we came to fix that, we found the code to reverse a stock entry already existed. It had been written. It had no callers — no button, no menu item, no route anywhere in the application. And wiring it up turned out not to be safe: six separate faults had to be repaired first, including one reader of stock positions that never checked the cancelled flag at all, so a reversed receipt would have gone on counting for ever.

The full account is in the piece on code that was written and never wired. The part that belongs here is why nobody had ever asked for the button: because a workaround existed and it worked. Somebody knew how to make the number look right again with a second entry and a note. Within months that was simply how a wrong receipt got fixed. The gap had not closed. It had been staffed.

How a correction should work#

Not by editing the original row. A receipt that can be edited is a receipt nobody can rely on, because the number you are reading today is not necessarily the number that was entered.

The correct shape is two rows written in one movement: the original marked cancelled, and a reversing entry of the opposite sign which is itself born cancelled. A reader that filters out cancelled rows sees neither. A reader that forgets to filter sees both, and both add to zero. The answer is right under either reading, which is what you want when you cannot personally audit every piece of code that will ever count your stock.

Add two more things and it is finished: state the effect in numbers before acting — the store reads this much, cancelling this leaves that much — and require a reason that actually reaches the record. A cancellation with no stated reason is an unexplained hole in the stock ledger, and unexplained holes are what audits are made of.

What a good GRN buys you#

Once your side has an independent, timestamped, correctable record of what arrived, three things become possible that were not possible before.

You can hold the invoice against it, which is three-way matching and is the single largest source of recovered money in purchase accounting.

You can hold your book stock against physical stock, and when they disagree you have dated entries to walk back through rather than a shrug. The wider version of that disagreement is why the site's numbers and the office's diverge.

And you can answer the question a vendor asks six weeks later — are you saying we short-delivered you? — with a document written on the day by the person who counted, rather than with an opinion.

The vendor's paper says what they sent. Yours says what you got. Keep both.

• The purchase order. What we agreed to buy, at what rate, in what unit.
• The goods receipt note. What our side says arrived.
• The invoice. What the vendor says we owe.

Each is written by a different person at a different moment with a different interest. That is the entire value of the method. If any two of them were written by the same side, the check that compares them proves nothing.

What you are actually comparing#

Not just the total. The total is the least informative number on an invoice, because two errors of opposite sign hide inside it perfectly.

Match line by line, and match four things per line:

1. The material. The same item, not a similar one.
2. The quantity. Invoice against receipt, not invoice against order — the order is what you wanted, the receipt is what came.
3. The rate. Invoice against order, because the rate was agreed in advance and the delivery has no opinion about it.
4. The unit. The most quietly expensive of the four. A rate agreed per tonne and invoiced per quintal is a factor of ten, and it looks like a perfectly ordinary line.

Then the arithmetic: quantity times rate, plus tax, equals the line total. Invoices are typed by people and the arithmetic is wrong more often than anyone expects.

The three ordinary outcomes#

All three agree. Pay it.

Receipt is less than invoice. The vendor is charging for material that did not arrive, or arrived short. This is what the method exists to catch. It is also where you find out whether your goods receipt notes were really written by your side or copied off the vendor's challan, because if they were copied this case can never occur.

Receipt is more than invoice. More arrived than is being charged for. Do not simply pay the lower figure and enjoy it. Either a second invoice is coming for the balance, or somebody has delivered to the wrong site, and both are better discovered now than at year end.

The tolerance question#

Nobody blocks a payment over a rupee. So a tolerance is set: a small percentage or absolute value inside which the three are treated as agreeing.

Two things about tolerances are worth stating plainly.

The tolerance must be defined once, centrally, and visible. A tolerance that each approver applies by judgement is not a tolerance, it is permission to approve anything.

And it must apply to the difference, not to the total. A tolerance expressed as a percentage of a large invoice is a large number of rupees, which means the checks get weakest exactly where the money is biggest. That is the wrong way round.

Where the method actually fails#

Not on the comparison. The arithmetic is easy. It fails on the cases nobody listed when the process was designed.

Partial deliveries. One order, five lorries, five receipts, one invoice. Now the match is many-to-one and every naive implementation either refuses it or matches against the first receipt and reports a shortfall that is not real.

One delivery, several orders. A vendor consolidates. The reverse problem.

Free material, samples, replacements. A load arrives with a receipt and will never have an invoice. If your process requires an invoice for every receipt, these sit open for ever and eventually somebody is told to ignore that queue, which kills the queue for everything.

Rate revisions mid-order. The order says one rate, a later agreement says another, and the agreement lives in a WhatsApp message. The match will fail correctly and for a reason nobody can find.

Payment before delivery. This one breaks more systems than the rest combined, and we broke ours with it.

The one we got wrong#

In our own process, money often has to move before a lorry will be dispatched. That is a commercial reality, not a policy choice.

Our software matched an incoming delivery challan against open purchases — and the matcher considered only purchases that had not been paid. So by the time material actually arrived, the correct purchase was always in the paid state, and was therefore never a candidate. The challan matched nothing, and a challan matched to nothing appears on no screen at all.

The three-way match was structurally impossible for the exact class of order it mattered most for. Nothing failed loudly. The photographs kept arriving and the result kept being invisible.

A related fault sat on the money side of the same process. A payment made in stages — an advance, then a balance — never wrote the field that meant this is paid, because when a payment has a schedule the stages are the payment record. Every query that asked "is the paid date set?" was blind to every rupee that had moved in instalments. That story is a fact that had no owner, and its lesson is the same as this one: the rule was right and the enumeration of cases was incomplete.

Asking rather than blocking#

There is a temptation, once you have a match, to make it a gate: no match, no payment.

We came to a different arrangement, and it has held up. On every payment awaiting signature the system says either delivery challans filed or, in amber, no delivery challan yet — money before material?

It is a question, not a block. Some payments rightly precede material, and the person signing is entitled to know they are making that choice rather than having it made for them. A hard block on a legitimate case teaches people to find the override, and once the override is habitual you have neither a block nor a question. It has a cost at the other end of the transaction too, where the same three documents decide whether a contractor is paid on time.

That distinction — between a system that refuses and a system that proposes and lets a person decide — turns out to matter far more than the strictness of the rule itself.

What to check on your own process#

Take one order that was delivered in parts and paid in stages. Follow it end to end and ask, at each step, which document the system compared against which.

If you cannot find three independently authored numbers, you do not have three-way matching. You have a form.

Its purpose is comparison. If two contractors are given the same list of items with the same quantities in the same units, then their totals mean something when set side by side, because they are pricing the same thing. Without it, every quotation is a different shape and comparing them is guesswork dressed up as procurement.

That is the whole idea. Everything difficult about a BOQ comes from the gap between that idea and a real site.

The anatomy of a line#

A single BOQ line has five parts, and people usually read two of them.

The item code. Boring, and the most useful thing on the page. It is what lets you follow one item from the estimate through the bill through the measurement sheet to the payment certificate. If your codes change between documents you have no thread to pull, and the same requirement on the accounts side is cost heads that survive a project.

The description. The actual contract. This is where the argument will happen. "Providing and laying" is a different scope from "laying". A description that names what is included and does not name what is excluded has told you very little.

The unit. Cubic metre, square metre, running metre, tonne, number, kilogram, quintal, lump sum. Read this before the rate, every time. A rate is meaningless without it, and mixed units within a bill are one of the most reliable sources of dispute there is — enough that we wrote about the unit of measure and where it leaks money on its own.

The quantity. Estimated, not guaranteed. More on this below, because it is the single biggest misunderstanding.

The rate. What the contractor is willing to do one unit of that item for, including everything the description says is included.

The quantity is an estimate#

This is the thing to internalise.

In most forms of measured contract, the quantities in a BOQ are the designer's best estimate of what the drawings imply. They are there so that tenders can be compared. They are not an order for that much work, and the contractor is not entitled to be paid for them if less work happens.

What gets paid is what gets measured, at the agreed rate, when the work is done. The bill provides the rate; the site provides the quantity.

This is why the difference between the quantity on paper and the quantity on the ground is a normal condition rather than a scandal — and also why it must be recorded rather than argued about later. That difference has its own piece: why measured and docketed quantities disagree.

Reading for what is missing#

An experienced reader spends most of their attention on absence.

• Is the preliminaries section priced, or spread? Site establishment, supervision, temporary works and insurance have to be paid for somehow. A contractor who prices them at nearly nothing has loaded them into the rates, which is fine as long as you know, and expensive to discover later if the quantities move.
• Which items have suspiciously high rates against small quantities? This is front-loading, and it is entirely rational behaviour. If a contractor expects a quantity to grow, they price that item high. Look at the items where the design is least settled.
• What has no line at all? The most costly omissions are the ones with no row to notice. Dewatering, shoring, disposal of excavated material, cutting and making good, testing. If it is not an item and not explicitly in a description, somebody will claim it as extra, and they will usually be right.
• Is there a provisional sum or a prime cost sum? These are placeholders for work that is not yet designed or priced. They are honest devices, but they are not commitments, and a total that leans heavily on them is a total that has not been fixed.

The rate is not the price#

A low rate on the biggest item wins tenders. Whether it survives contact with the site is a different question.

The useful discipline when comparing two bills is to ignore the totals for the first pass and compare rates item by item on the ten or fifteen lines that carry most of the money. Construction bills are extraordinarily top-heavy — concrete, steel, blockwork, finishes. If two bidders differ wildly on one of those lines, either one of them has misread the description or one of them knows something.

From the bill to the money#

The BOQ does not stop being useful once the contract is signed. It becomes the skeleton of every payment.

A running account bill is almost always the same list of items with a new column: quantity executed this period, cumulative quantity, cumulative value, less what was already certified. The clean version of that arithmetic depends entirely on the item codes staying constant. When somebody renumbers the bill halfway through a project, every cumulative figure in the file loses its meaning and has to be rebuilt by hand.

Retention, deductions, advances and set-offs all sit below that same structure. So the discipline of a well-formed BOQ pays out for the whole life of the job, and a sloppy one is paid for monthly, for years.

Three checks worth doing on any bill you are handed#

1. Add it up yourself. Not to catch fraud. To catch a wrong formula in a spreadsheet, which is far more common and just as expensive.
2. Pick five random lines and read the description out loud. If you cannot say what is included and what is not, neither can the person who will build it, and the gap between those two readings is the claim.
3. Check that each unit matches its item. Reinforcement by weight, concrete by volume, formwork by contact area, painting by area, piling by length. A unit that does not match the physical nature of the work is usually a copy-paste error, and it will be found at measurement time by whichever party it favours.

The short version#

A bill of quantities is a fair way of asking several people the same question. It is not a forecast, not an order, and not a promise about how much work there will be.

Read the descriptions like a contract, the units like an engineer and the quantities like an estimate, and most of the surprises stop being surprises.

It is a strength. Specifically, it is the characteristic compressive strength in newtons per square millimetre, measured on standard cubes at twenty-eight days. The M stands for mix.

So M25 concrete is concrete specified to reach a characteristic cube strength of 25 N/mm² at 28 days. That is the whole definition, and each part of it is doing work.

"Characteristic" is not "average"#

This is the part that gets skipped, and it is the most important.

Characteristic strength is not the mean of your test results. It is a value below which only a small proportion of results is expected to fall — the code defines it as the strength below which not more than five per cent of test results are expected to lie.

Concrete is a variable material made in the open air by people with buckets and lorries. Test a hundred cubes from a well-controlled batching plant and you get a spread, not a number. Specifying the average at 25 would mean that something close to half of your concrete is weaker than the design assumed, which is not a position any structural engineer will accept.

So a mix designed for M25 is targeted well above 25, by a margin that depends on how consistent that particular plant and that particular supply chain actually are. A plant with tight control needs a smaller margin. A plant with variable aggregate needs a bigger one. The margin is a statement about the process, not about the concrete.

Two practical consequences follow.

A single cube result below 25 is not automatically a failure. The specification is about a distribution, and the code sets out how results are grouped and judged. A single low cube is a signal to look, not a verdict.

A single result above 25 does not prove compliance either. People misuse this constantly in both directions.

"At twenty-eight days"#

Concrete continues to gain strength for a long time. Twenty-eight days is the conventional age at which it is judged, and it was chosen as a practical compromise between waiting for the strength to develop and needing an answer before the building is finished.

It has one very uncomfortable property: by the time you have the result, the concrete has been in the structure for four weeks and quite possibly has three floors on top of it.

That is why seven-day results are taken as well. They are an early indication — a bad seven-day result is a reason to stop and think, not a certification of anything. The relationship between the seven-day and twenty-eight-day figure varies with the cement, the mix and the weather, so treating it as a fixed percentage is a mistake that has led people to accept bad concrete and reject good concrete in roughly equal numbers.

The full mechanics of the test, and what actually goes wrong with it, are in the piece on the concrete cube test.

Grade is not a mix ratio#

An older way of specifying concrete is by nominal proportions — one part cement, so many parts sand, so many parts aggregate. You will still hear these on site.

Nominal mixes are permitted only for the lower grades. Above that the mix has to be designed: proportions worked out for the specific materials, tested by trial, and adjusted. This is not bureaucracy. The strength of concrete depends much more on the water-cement ratio than on the cement content alone, and a nominal proportion says nothing at all about water. Two batches at the same nominal ratio, one made with a wet mix because it was easier to place, can differ enormously in strength.

Which is why the argument about water on site is not really an argument about workability. It is an argument about strength, conducted in the language of convenience, and it has its own piece: the slump test.

What a grade does not tell you#

Grade is compressive strength and nothing else. A specification often carries several other requirements alongside it, and they are not implied by the M number:

• Exposure conditions and durability. Minimum cement content, maximum water-cement ratio and minimum grade are set by how aggressive the environment is. A structure in a coastal or chemically aggressive setting has requirements that a strong-but-porous mix will not satisfy.
• Maximum aggregate size, which is governed by the spacing of the reinforcement and the thickness of the member.
• Workability, expressed as a slump range appropriate to how the concrete will be placed.
• Cement type, which affects heat of hydration and rate of gain.

A load that meets the strength and misses the durability requirements has passed the test everybody watches and failed the one that decides how long the structure lasts.

The record that outlives the pour#

The thing nobody thinks about on the day is that the grade is a claim you may have to defend for decades.

For each pour, the useful record is: the date, the location in the structure, the grade specified, the quantity, the supplier or the mix used, the challan or batch reference, the slump measured on arrival, who received it, and the seven- and twenty-eight-day cube results with their identification marks.

Most of that is captured at the barrier, on a load the gate should already have been expecting — why a lorry surprises the gate.

That is not a long list, and almost nobody has it complete. We brought eight months of concrete history into our own system from a spreadsheet and found the value was in exactly those fields — the receiving officer, the challan number, the rate, the slump, and the cube results where they had been taken. What made the import trustworthy was that it reconciled: the number of rows, the total volume, and the total value all had to reproduce the figures the register claimed before a single row was written. Two rows had to be hunted down first because a serial number was blank on one and mistyped on the other.

A parse that cannot reproduce the total it claims is not a parse anybody should import. The same is true of a concrete register. If the loads on the page do not add up to the volume in the structure, one of the two is wrong, and finding out which one after the fact is very expensive.

The short version#

M25 means: designed so that, at twenty-eight days, no more than a small proportion of standard cube results fall below 25 N/mm².

It is a statistical statement about a process, not a label on a lorry.

Concrete arrives, somebody fills a set of steel moulds from it, those cubes are cured in water, and at a stated age they are crushed in a machine that records the load at which they fail. Divide that load by the area of the face and you have a compressive strength. Compare it with what was specified and you have an answer.

The procedure is simple enough to describe in a paragraph. Almost everything that goes wrong with it happens in the ten minutes at the beginning, when nobody is watching.

What the test is measuring#

A cube is not the structure. It is a sample of the same material, treated as well as anybody knows how to treat it, so that its result represents the best the concrete could do.

That is a deliberate choice and it has a consequence people find counter-intuitive: a cube result tells you about the concrete as supplied, not about the concrete as placed. Poor compaction, poor curing and bad weather in the structure are real problems that a perfect cube result will not reveal. The cube answers one question — was the material we were given capable of the specified strength — and it answers it well. It answers nothing else.

The first ten minutes#

The sample must be representative. Taken from the discharge of the load, not from the first splash and not from the scrapings at the end. A sample taken from the wrong part of a load is a test of something that was never in the structure.

The moulds must be right. Clean, correctly sized, properly oiled, and assembled so the faces are square. A distorted mould gives a cube with a face that is not flat, which changes how the load is applied and therefore what number comes out.

Compaction has to be done properly and consistently. Air voids left in a cube reduce its strength substantially. A cube that was rodded half-heartedly because the person was in a hurry will fail, and the failure will be blamed on the supplier.

They must be marked. This is the one that ruins whole months of testing. A cube with no identification, or with an identification that has washed off in the curing tank, is a result belonging to nothing. It cannot be attached to a pour, a location, a grade or a supplier. It is a number with no owner, and the only honest thing to do with it is discard it — which means the pour it came from has no test at all.

Curing is where the argument starts#

Cubes are cured in water at a controlled temperature until they are tested. That is the standard condition, and it exists so that results from different sites are comparable.

It also means the cubes are treated better than the structure almost always is. Somebody will point this out, usually when a result is disappointing, usually in the form "the cubes were not cured the same way as the slab". They are correct about the fact and wrong about what it implies. The cube is a control sample. Its job is to hold everything constant except the concrete. If you cure cubes the way the slab was cured, you have measured the curing, not the concrete, and you have lost the only comparable number you had.

If the concern is the structure rather than the supply, that is a different test — cores taken from the actual member, or non-destructive methods — and those come with their own corrections and their own arguments.

Seven days and twenty-eight days#

Twenty-eight days is the age at which concrete is judged. Seven-day cubes are taken as an early warning.

The temptation is to convert one into the other with a fixed ratio. Resist it. The relationship depends on the cement, the mix, the admixtures and the temperature, and the range across ordinary construction is wide enough that a fixed factor will cause both false alarms and false comfort.

What a seven-day result is genuinely good for: telling you that something is badly wrong, four weeks earlier than you would otherwise know. A seven-day result far below what that mix has historically produced is a reason to stop pouring from that source and find out why. It is not, by itself, a rejection.

What a failing result actually means#

Not much, on its own. Compliance is assessed on groups of results against criteria set out in the code, not on individual cubes, precisely because the material is variable and the test has its own scatter.

The sequence when results are unsatisfactory is investigative rather than punitive: check the test itself, check the records for that batch, then if necessary move to tests on the structure. Skipping straight from one low cube to demolition, or from one low cube to a shrug, are the two commonest errors and they are made by different people for the same reason — neither has understood that the specification is a statement about a distribution.

The grade specification itself, and why it is a statistical claim rather than a label, is explained in what M25 actually means.

The record is the deliverable#

A cube test produces a number. The value of that number is entirely a function of what it can be attached to.

Each result needs, at minimum: the date the cubes were cast, the date tested, the identification mark, the grade, the pour and its location in the structure, the supplier or batching source, the challan or batch reference, the slump recorded on arrival, and the load at failure.

Without the pour location, you cannot answer the only question that ever gets asked later: is the concrete in this particular column all right? Without the challan reference you cannot connect the result to a load, and therefore cannot connect it to a supplier or to a payment. That connection is what makes cube results into something more than a filing exercise, and it is the same connection that makes a delivery challan worth capturing properly in the first place.

When we imported eight months of a concrete register into our own system, the fields that turned out to carry the value were exactly these — the receiving officer, the challan number, the rate, the slump, and the seven- and twenty-eight-day results where they had been taken. The rows without them were not wrong. They were just no longer evidence of anything. They are also among the few unrepeatable items in what belongs in a handover file, because nobody can cast a cube for a pour made three years ago.

The short version#

The crushing machine is the least interesting part of the cube test.

Sample properly, compact properly, mark the cube so the mark survives a month under water, cure it to the standard condition even when somebody objects, and record the result against the pour it came from.

Do those five things and the number means something. Miss any one of them and you have spent four weeks producing a figure you cannot use.

That is the entire test. It takes about two minutes and needs a cone, a rod, a flat plate and a ruler. It is the cheapest quality check on any construction site and one of the most frequently skipped.

What it is measuring#

Workability. How easily the concrete can be placed and compacted without segregating.

Slump is not strength, and it does not measure strength. What makes it important is that the easiest way to increase slump on site is to add water, and adding water reduces strength. So slump is the observable that stands in front of the invisible thing you actually care about.

A specification will name a slump range appropriate to the work: stiffer for something that must hold its shape, wetter for a heavily reinforced section where the concrete has to flow between bars. Both the top and the bottom of that range matter. Too low and it will not compact, leaving voids. Too high and either water has been added or the mix has been designed wet, and in the first case the strength has already gone.

The argument, in its usual form#

Concrete arrives. Somebody looks at it and says it is too stiff to place. A hose appears. Two buckets of water go in, the drum turns, and the load becomes much easier to handle.

Everybody in that conversation is behaving reasonably. The person placing the concrete has a real problem — stiff concrete in a congested section genuinely will not compact, and badly compacted concrete is also weak. The driver wants to discharge and leave. Nobody involved is trying to weaken the building.

What has happened is that a decision about strength has been made by the person holding the hose, on the basis of how the mix looks, with no record.

The correct answer is almost never water. It is either an admixture, which is what admixtures exist for, or a mix designed for the placement conditions in the first place, or a different pour sequence. All of those require somebody to have thought about it before the lorry arrived.

Where and when to test#

At the point of discharge, from the load you are about to place, before it goes in. Not at the plant, not from the first spill, and not after water has been added — which sounds obvious and is the most common way the test is defeated.

There is a timing subtlety worth knowing: concrete loses slump as it stands. A load tested an hour after batching will read lower than the same load at the plant, without anybody having done anything wrong. If the site is a long way from the plant or the truck queued, that loss is real and expected. The specification and the mix design have to accommodate it, which is a conversation with the supplier and not a reason for a hose.

Reading the shape, not just the number#

The way the concrete slumps tells you something the ruler does not.

• A true slump, where the mass settles evenly and keeps its shape, is what you want to see.
• A shear slump, where one side slides off, suggests a mix that is not cohesive. The number is unreliable and the test should be repeated.
• A collapse, where it spreads out flat, means the mix is far too wet for this test to say anything useful about it.

Two loads can produce the same reading with completely different behaviour in the shutter. Somebody who has watched a hundred slump tests learns more from the four seconds after the cone lifts than from the measurement.

Why it is skipped#

Because it is the only quality check that costs the site something at the exact moment it is performed.

Everything else about concrete quality is checked later or elsewhere. The cube test happens now and reports in four weeks, so it costs nothing today. The slump test happens now, reports now, and its result may require somebody to reject a load with a queue of lorries behind it and a gang standing idle.

That is the honest reason it does not get done. Not ignorance. A test that can stop work is a test people find reasons not to run, and the reasons are always credible on the day.

Making it survive contact with a real site#

The only version of this that works is one where recording a slump is easier than not recording it, and where somebody other than the person under pressure sees the number.

That means the slump belongs on the same record as the load itself — the same row that carries the challan number, the vehicle, the grade, the volume and the receiving officer. That row is written at the barrier, which is why it matters what the gate has been told before the lorry arrives — why a lorry surprises the gate. Not in a separate register that a separate person keeps. A field on a form that already has to be filled costs nothing to fill; a second register costs a walk to the office, and the walk is what actually decides whether it happens.

It also means the number has to be visible afterwards. A slump reading that disappears into a file is a reading that only ever gets looked at during a dispute. Held beside the grade and the cube results for the same load, it becomes something else: the first place anybody looks when a twenty-eight-day result comes back low. High slump on arrival and a poor cube result four weeks later is a pattern that explains itself, and you can only see the pattern if the two numbers live in the same place.

This is a small instance of a much more general point about site records — that a record which requires an extra journey is a record that exists in theory. We have written about the same problem in the context of a gate register somebody will actually keep.

The short version#

Slump is a two-minute measurement of workability that stands in for the thing you cannot see, which is how much water went into the concrete.

Test at discharge, before anything is added. Watch the shape as well as the ruler. Write the number on the same row as everything else about that load.

And when somebody reaches for a hose, understand what is actually being decided, and by whom.

This happens constantly, on every site, with every material, and the ordinary response is to treat it as either a rounding matter or an accusation. It is usually neither. The gap between the docketed quantity and the measured quantity has half a dozen ordinary causes, and knowing which one you are looking at is the difference between a conversation and a dispute.

The two numbers are answers to different questions#

The docket says what the seller loaded, measured by the seller's method, at the seller's premises, at dispatch.

Your measurement says what your side counted, by your method, at your gate, on arrival.

Written like that, it would be surprising if they always matched. Same material, two places, two times, two methods, two people, each with a reason to round in a particular direction.

The ordinary causes#

Different methods of measurement. Steel bought by weight and counted by piece. Sand ordered by volume and delivered by a lorry whose capacity is nominal. Aggregate weighed at a weighbridge against aggregate estimated from the height in the body. Each method has a tolerance and the two tolerances do not overlap neatly.

Moisture. Sand and aggregate carry water, and the amount changes with the weather and with how long the stockpile has been standing. A load weighed after rain weighs more and contains no more usable material. If one end weighs and the other counts volume, this alone will produce a persistent, seasonal, completely honest discrepancy.

Bulking. Damp sand occupies more volume than the same sand dry or saturated. A truck body that holds a certain volume holds a different mass depending on condition. Volumetric measurement of sand is unreliable for exactly this reason, and everybody knows it, and it is done anyway because it is quick.

Losses in transit. Spillage, dust, breakage in bagged material, a bag split on the tailgate. Real, small, and not usually anybody's fault.

Timing of the count. Material counted as it comes off, versus counted after it is stacked, versus counted the following morning from a heap. Each further step adds a chance to lose or double-count.

Partial delivery. One order, several vehicles. If the docket is written for the order and the arrival is one vehicle, the two figures are not comparable at all and the whole comparison is a category error.

The causes that are not ordinary#

Deliberate short delivery exists. So does a weighbridge that reads generously for a particular customer, and material sold twice.

The useful point is that you cannot tell these apart from the ordinary causes by looking at a single delivery. A one-off gap is noise. What identifies the other kind is pattern: the same vendor, the same vehicle, the same driver, the same direction of error, over time.

Which means the entire diagnostic capability depends on whether your measured quantities were recorded at all. If your goods receipt notes were written by copying the vendor's docket — as they very often are, because it is faster — then every gap is zero, the pattern cannot exist, and you have no way of knowing which of the two situations you are in.

Record the gap, do not resolve it#

The instinct when the two numbers differ is to pick one and write it down. This is the wrong move and it is nearly universal.

Both numbers are facts. The docketed quantity is a fact about what the seller says they sent. The measured quantity is a fact about what your side counted. Writing down only one of them destroys information that cannot be recovered later, and the information destroyed is precisely the information a pattern is made of.

The right shape is three fields: docketed, measured, and the difference — with a place for a reason when somebody knows one. Short by two bags, one split on tailgate is a complete and useful record, and the supplier has the same interest in it being written on his own copy at the gate — the challan that protects the supplier. Received: 98 is not, because next month nobody can tell whether it was ordered as 98 or ordered as 100.

We arrived at the same conclusion on the money side of the business, from a completely different direction. When a payment is made for less than the agreed amount, the system now asks why before it accepts, and the shortfall and its reason land on the record together. The agreed figure stays reconstructible as paid plus deducted. That story is paying less than agreed, and the principle is identical: a difference with a reason is information, and a difference silently absorbed is a number nobody can ever explain again.

Which number should stock be posted at#

The measured one. Always.

Stock is a claim about what is physically present. The docket is a claim about what was dispatched. Posting the docketed quantity into stock means your stock ledger is a copy of your vendors' dispatch notes, which is a fine record of what you were told and a poor record of what you have.

The docketed figure still matters — it is what the invoice will be based on, and reconciling those two is the entire purpose of three-way matching. But it belongs on the purchase side of the ledger, not the stock side.

What to do about a persistent gap#

1. Check the method first. Nine times in ten, a systematic gap is a systematic difference in how the two sides measure, and it is fixed by agreeing a method rather than by an argument about honesty.
2. Agree a tolerance in writing, per material. Cement in bags and sand by the lorry do not deserve the same tolerance and should not be given one.
3. Fix the measuring point. Same place, same equipment, same stage of unloading, every time. Most gaps that look like theft are two people measuring at different moments.
4. Then look at the pattern. After the first three, whatever is left is worth a conversation with the vendor, and you will have dated records to have it with.

The short version#

Two different people measured two different things at two different moments. Of course the numbers differ.

Write both down. Write the difference down. Write the reason down when there is one. The gap is not the problem; the gap with no record is.

Most advice about store management assumes conditions that a site does not have. What follows is the part that survives.

Four things, in order of importance#

Everything in is recorded at the moment it comes in. Not that evening, not from the pile of challans. The record has to be made by the person who counted, while they are counting.

Everything out is recorded against something. A project, a location, a work item, a person. Material that leaves the store to no destination is material that has left your knowledge, and no amount of stocktaking afterwards will tell you where it went.

Every material has exactly one unit. One. Not "bags, or tonnes when it comes loose".

Corrections are entries, not edits. A number that can be quietly changed is a number nobody can rely on.

Get those four and the store is manageable. Miss any one and you are running a guessing operation with a ledger attached.

Why the issue side is the one that fails#

Receipts get recorded because there is a lorry, a driver, a challan and somebody waiting for a signature. The event has ceremony. It is hard to miss — provided the barrier knew the load was coming, which is the subject of why a lorry surprises the gate.

Issues have none of that. A carpenter needs six sheets of ply and takes six sheets of ply. Somebody needs another two bags of cement at four in the afternoon. There is no external party, no paper, and nobody standing there waiting. So the issue register gets written up "later", and later is where site records go to die.

The consequence is systematic and always in the same direction: book stock is higher than physical stock, because receipts are complete and issues are not. Then a stocktake shows a shortfall, and the shortfall gets called wastage or pilferage, when a large part of it is simply issues that were never written down.

If you are going to be strict about one half of a store, be strict about the half that leaves.

Make the issue cheap to record#

Two things make an issue register work.

It must be doable by the person taking the material, where they are standing. A register kept in a cabin that requires a walk is a register filled in from memory at the end of the day. A phone in the storekeeper's hand is worth more than a beautifully designed book on a desk.

It must accept the way people already talk. People do not say "issue quantity six, unit number, material plywood 12mm". They say "6 ply gaya, second floor". A record that demands a form's vocabulary gets a form's compliance rate.

We learnt this the hard way in our own tools. Our software recognised a photograph from site as a delivery only if the caption contained one of four words — challan, bilty, GRN, delivery. Measured against four hundred captions the site team had actually sent, those four words matched exactly two. What people really wrote was the material and a quantity, or the name of the vehicle that brought it, or a plain list of items. Reading those three shapes instead took the match rate from two to thirty-four out of the same four hundred.

The vocabulary was not the site's problem. It was ours. There is a longer piece about that in the words the site already uses.

One unit per material, and mean it#

A store that records cement in bags on Monday and in tonnes on Thursday does not have a stock figure. It has two stock figures added together.

Choose the unit that the material is physically handled in, not the one it is bought in or the one it is consumed in. Cement in bags, because bags are what get carried. Steel in kilograms if it is weighed and in pieces if it is counted, but never both, and if that means a conversion at the receipt stage then do the conversion at the receipt stage where somebody can check it.

Conversions belong at the boundary, once, with the factor written down. A conversion applied ad hoc, differently, by whoever is entering that day, is the most expensive kind of error because it is invisible in every individual record and only shows up as an unexplained gap in the total. It has its own piece: the unit of measure.

The correction problem#

The storekeeper types the wrong number. It will happen. Not occasionally — regularly, because the conditions are a phone, a lorry and the end of a long afternoon.

What matters is what happens next. If there is no way to reverse an entry, the correction goes on paper, into a note, and into the head of the one person who remembers which entry was the bad one. That is not a hypothetical; it is what we found in our own system, where the code to reverse a stock entry had been written and had never been given a button.

A reversal has to do four things or it makes matters worse:

• Write a reversing entry, not an edit, so the history stays readable.
• Be refused if the stock has since gone out. Reversing a receipt after most of it has been issued drives the balance below zero, silently, which is not a state a physical store can be in.
• Be restricted to people entitled to do it, which is not the same as "whoever's name is on the row".
• Carry a reason into the record. A reversal with no stated reason is an unexplained hole, and unexplained holes are what a stocktake turns into an argument.

Stocktaking without theatre#

Count often, count small, count unannounced. A full stocktake once a quarter produces one enormous unexplainable variance. Counting three materials a week produces small variances you can still trace to a week's worth of entries.

And when book and physical disagree, resist the urge to make the book match the floor with a single adjusting entry. Adjust, yes — but record the adjustment as its own dated entry with its own reason, so that next quarter somebody can see whether the same material keeps needing adjusting. That pattern is the actual finding. The number itself is not. There is more on this in physical stock against book stock.

The short version#

A site store fails on the way out, not the way in.

Make issues as easy to record as receipts are, fix one unit per material, never edit a number that has already been read by somebody, and count small and often.

The rest is shelving.

That definition is uncontroversial and almost useless, because the difference has at least five components, they behave completely differently, and nearly every site adds them together into one number and then argues about it.

The five things inside the wastage figure#

Design allowance. Some material is consumed by the nature of the work and was always going to be. Lap lengths in reinforcement. The cover that is thrown away when a bar is cut to length. Mortar joints. This is not waste in any meaningful sense; it is the difference between the theoretical quantity from a drawing and the practical quantity a builder has to buy.

Cutting loss. Offcuts. A standard bar length divided into required lengths leaves a remainder. Good bar bending schedules and good cutting plans reduce it; nothing eliminates it.

Handling and storage loss. Split bags, cement gone hard because it was stacked against a wall in the monsoon, aggregate lost into the mud at the bottom of a stockpile, tiles broken in transit.

Over-ordering and over-issue. Material drawn from the store that was never needed and never returned. This is the largest component on most sites and the least discussed, because it is nobody's fault in particular.

Loss. Material that left the site and was not used on it.

The first two are predictable and should be planned — and priced, because a contractor who leaves them out of his rate pays for them from profit, as quoting a rate you can live with sets out. The third is reducible by ordinary competence. The fourth is a process failure. The fifth is a security matter. Rolling them into one percentage and comparing it to a norm tells you which of those five to work on: none of them.

Norms are a starting point, not a standard#

Every organisation has wastage norms for common materials, usually inherited, usually expressed as a percentage. They are useful as a first check — a figure far outside the norm is worth looking at.

But two cautions.

A norm is an average over conditions that may not be yours. Cutting loss on reinforcement depends on the member sizes and the standard lengths available; a project of small members will genuinely waste more steel than one of long spans, and no amount of discipline changes that.

And a norm quickly becomes a target from below. If the allowance is a certain percentage, consumption tends to rise to meet it, because nobody is questioned while they are inside the allowance. The norm stops being a control and becomes a budget.

Why the number is usually wrong before anybody analyses it#

To calculate wastage you need three quantities: what was purchased, what was issued, and what the work actually required.

The first is generally reliable, because it comes with invoices.

The second is not, because site stores fail on the way out. Receipts are recorded — there is a lorry and a driver and a signature. Issues are recorded later, from memory, or not at all. So the issue figure is systematically low.

The third is the theoretical quantity from the drawings or the measurement book, and it is only as good as the measurement.

Two of your three inputs are soft, and the wastage figure is a difference between them, which means the error in it is the sum of both errors. A number computed from a low issue figure and an approximate theoretical figure is not evidence of anything, and building a control regime on top of it produces arguments rather than savings.

Reconciliation is per-material and per-period#

A single site-wide wastage percentage answers no question anybody has.

The useful unit is one material, over one period, on one project:

• Opening stock
• Plus received
• Less issued
• Equals closing book stock
• Compared with physical stock

Then separately: material issued, against material the measured work required.

Those are two different reconciliations answering two different questions. The first asks whether the store's records are right. The second asks whether the work consumed what it should have. Sites routinely conflate them, and then cannot tell a recording failure from a consumption failure — which are fixed by completely different people doing completely different things.

The materials worth being strict about#

Not all of them. Being equally strict about everything is a way of being strict about nothing.

Rank by value at risk, which is quantity times rate times how easily the material walks. On most projects that puts cement, reinforcement steel and finishes at the top, and it puts a lot of the items people fuss about near the bottom.

For the top three or four materials, it is worth doing the full reconciliation monthly with real counts. For the rest, a quarterly count and a sensible eye is enough. The effort saved on the tail is what pays for doing the head properly.

Measuring loss requires measuring the ordinary#

The uncomfortable conclusion is that you cannot detect theft on a site that does not record its ordinary consumption accurately, because theft is a residual and a residual is only visible when everything else in the equation is known.

This is the same structural point as why measured and docketed quantities disagree. A gap becomes information only when the ordinary causes of that gap have been recorded and subtracted. Otherwise every gap is explicable by any of five stories and the argument goes to whoever is more persistent.

So the sequence is: fix the issue register, fix the units, count the top materials monthly, record differences with reasons — and only then start drawing conclusions from the residual. It is slower than everybody wants and it is the only order that works.

The short version#

Wastage is five different things wearing one number.

Separate design allowance from cutting loss from handling loss from over-issue from actual loss, because each has a different fix and only one of them is a security problem.

And before you interpret the figure at all, check whether your issue records are complete. On most sites they are not, and everything downstream of them is arithmetic on a guess.

For every member it lists the bar mark, the diameter, the shape, the cut length, the number of bars, the total length and the weight. Added up, it is the steel order. Handed to a bender, it is the cutting list. Compared against what was delivered and what was fixed, it is the reconciliation.

One document doing three jobs is why errors in it are expensive: they do not show up once, they show up in the order, in the yard and in the measurement, and by the time the third one contradicts the first, three weeks have passed.

Weight from diameter, and where the number comes from#

Steel is ordered in kilograms and drawn in millimetres, so every schedule contains one conversion.

It is not a magic constant. Take a round bar of diameter d millimetres. Its cross-sectional area is π·d²/4 square millimetres. Steel has a density of about 7,850 kilograms per cubic metre. Convert the units and the mass of one metre of bar comes out as roughly d² divided by 162 kilograms.

That is the whole derivation, and it is worth doing once rather than memorising, because then you know two things the constant alone does not tell you.

First, it assumes plain round section and nominal diameter. Deformed bars have ribs, and their actual mass per metre is governed by standards that permit a tolerance either side of nominal. Your bar may legitimately weigh slightly more or less than the arithmetic says.

Second, the tolerance is a band, and a supplier who consistently sits at one end of it is delivering consistently less steel per kilogram of invoice than one who sits at the other. Nothing improper has happened. But if you are reconciling fixed steel against purchased steel, this is a real component of the difference and it is not wastage.

The lengths that are not on the drawing#

The drawing shows where steel goes. The schedule has to show how it is cut, and several lengths appear at that step that never appeared on the drawing.

Laps. Bars come in standard lengths and members are longer than bars. Where two bars overlap, both are consumed for the overlap distance. Lap length is a design quantity, governed by the code and by the grade of concrete and steel, and it is where a lot of steel quantity lives.

Bends and hooks. A bar bent round a radius follows a longer path on the outside than the inside. The cut length is not the sum of the straight dimensions; standard bend deductions and hook allowances apply.

Cover. Dimensions on a drawing are usually to the face of the concrete. The bar stops short of that face by the cover. Every dimension has to be reduced, at both ends, and forgetting it is one of the most common schedule errors — consistently producing bars slightly too long, which fit badly and quietly increase consumption.

Chairs, spacers and support steel. Real, necessary, frequently absent from schedules, and then the site finds them from the offcut pile and the reconciliation never balances.

Where the schedule and the site disagree#

Even a perfect schedule will not match consumption, for reasons that are ordinary rather than suspicious.

Bars are supplied in standard lengths. Cutting a standard length into required lengths leaves an offcut. Whether that offcut is usable depends on whether a shorter bar is needed nearby, which depends on sequencing and on how tidily the yard is run. Two sites with identical schedules can differ substantially in purchased steel purely on cutting strategy, which is why that loss belongs inside the rate rather than being discovered in it — quoting a rate you can live with.

Then there is revision. Drawings change. If the schedule is revised and the already-cut steel is not, you have material that fits nothing and a reconciliation that will never close.

This is the same category of problem as the gap between measured and docketed quantities: an ordinary, explicable difference that becomes an argument only because nobody recorded the explanation at the time.

The version control problem#

A bar bending schedule is a live document on a live project, and it is very often the worst-controlled document on the site.

It exists as a spreadsheet. It gets emailed. Somebody at the yard has a printed copy from three weeks ago. The consultant has issued a drawing revision that the schedule has not caught up with. There is no single answer to "how much steel does this floor need", because there are four answers and they are all somebody's current file.

The practical minimum: every schedule carries the drawing number and revision it was prepared from, the schedule's own revision, and a date. If a bar is cut against a superseded schedule, that fact is discoverable afterwards rather than mysterious. The identifiers cost nothing and they are what makes a reconciliation possible at all.

The general form of this rule — that a record without a handle back to what it came from stops being evidence — is the same reason a concrete cube result needs its pour reference.

Reconciling steel, properly#

Three quantities, per diameter, per period:

• Purchased, from invoices and weighbridge slips, in kilograms.
• Issued from store to yard, in kilograms.
• Fixed in the work, from the schedule, for the members actually completed.

The difference between the first two is a store question. The difference between the last two is a consumption question. Keep them apart — running them together produces a single unexplainable figure, which is exactly the trap described in wastage on site.

Do it per diameter. A site-wide steel figure hides the case that matters most, which is one diameter being over-consumed because a schedule error is repeating in every member of the same type.

The short version#

A bar bending schedule is a cutting list, a purchase order and a measurement basis wearing one set of clothes.

The weight conversion is arithmetic you can derive rather than a constant you have to trust. The lengths that cause trouble are the ones not on the drawing — laps, bends, cover. And the errors that cost most are systematic ones, repeated in every member of a type, which is why reconciling by diameter finds things that reconciling by total never will.

The unit is where the money goes.

Why this particular error is so persistent#

Because it does not look like an error.

A wrong quantity looks wrong. Somebody ordered a hundred and got a thousand, and the person receiving it says something, because a thousand of anything arrives in a different sized vehicle.

A wrong unit produces a document that is internally consistent, arithmetically correct, printed neatly, and off by a factor. Quantity times rate equals amount. The line adds up. The invoice adds up. Every automated check passes. The only way to catch it is for somebody to know what a reasonable rate for that material in that unit looks like, and to be paying attention on the day.

The families of unit error#

Straight conversion. Tonne and quintal. Metre and foot. Square metre and square foot. Litre and kilogram for anything whose density is not one.

Nominal container units. Bag, load, trip, truck, brass. These are units in name only — they are containers whose contents vary. A "load" of sand is whatever that lorry holds, and the same word describes different volumes at two suppliers. Buying in container units and consuming in real ones is a permanent source of unexplainable variance.

Dimensional confusion. Running metre, square metre and cubic metre for the same item at different stages. Skirting bought by length, laid by length, measured by length, but ordered by area because somebody worked off the floor plan.

Weight against count. Steel, fasteners, fittings. Bought by weight, consumed by piece, and the conversion depends on the size — so the factor is correct for one diameter and wrong for every other.

Packaging against contents. Twenty bags, or twenty tonnes, of the same cement. The number twenty is the same on both documents.

The three places a unit must be fixed#

In the item master, once. One material, one stock-keeping unit. This is the first discipline of running a site store that survives contact with reality, and it is the one people compromise on first, because it seems reasonable to let cement be recorded in tonnes "when it comes loose". It is not reasonable. It means your cement balance is two numbers added together.

On the order. The rate and the unit are agreed together and neither is meaningful alone. An order that names a rate without naming the unit it applies to is an invitation, and the invitation gets accepted at invoice time — which is the same trap seen from the side doing the pricing, quoting a rate you can live with.

At the conversion boundary. Where a material genuinely arrives in one unit and is held in another, do the conversion once, at receipt, with the factor written on the record. Not in the head of whoever is entering. Not differently each time. The stored factor is what makes the entry checkable a year later.

Why unit errors survive automated checking#

Most purchase checking compares an invoice against a receipt against an order. Done properly, this is three-way matching and it catches a great deal.

It catches unit errors only if the unit is one of the fields compared. Very often it is not — the comparison is written to check material, quantity and rate, because those are the fields people think about. If order, receipt and invoice all carry a unit and the check ignores it, then a load ordered per tonne, received per tonne and invoiced per quintal passes cleanly, and the quantity comparison actively reassures you, because the numbers do differ by a factor and the tolerance test on the total is the only thing that might notice.

Add the unit to the comparison. It is one field and it closes an entire class.

The rate sanity check#

The cheapest defence anybody has against unit errors is a sense of what things cost.

If a purchase officer knows roughly what a tonne of a given material goes for, a line priced at a tenth or ten times that figure stops them, regardless of what the unit column says. This is not a system. It is a person, and it is the most effective control in most organisations.

Which means the system's real job is to keep that person's attention available by not spending it elsewhere. An approval queue full of routine items trains people to approve without reading, and once that habit forms the sanity check is gone. We have written about the same dynamic in the context of alerts that ring for everything: attention is a fixed supply, and a process that spends it on the ordinary has none left for the strange.

Where it shows up much later#

Unit errors are unusual in that they often do no visible damage for months.

The invoice is paid. Stock is posted at the wrong unit and the balance is wrong by a factor. Consumption is booked against the same wrong balance, so the error partly cancels itself in the reporting. Nothing is obviously broken.

Then a stocktake happens, and there is a variance of a size that cannot be explained by wastage, handling or anything else on the list in wastage on site. At that point the error is months old, spread across many transactions, and identifying it means walking back through every entry for that material.

That is why the discipline has to sit at the front. There is no efficient way to find a unit error afterwards.

A short checklist#

1. Does every material have exactly one stock unit, recorded centrally?
2. Does every order line carry a unit next to its rate?
3. Does the receipt record the unit the material actually arrived in, and the converted quantity, and the factor used?
4. Does the invoice check compare units, not just quantities?
5. Does anybody in the chain know what a reasonable rate per unit looks like for the top ten materials by value?

The fifth one is worth more than the other four together, and it is the only one that cannot be bought.

Everybody knows the exercise. Rather fewer get anything useful out of it, because the exercise is usually treated as a way of producing a corrected number rather than as a way of producing information.

The arithmetic#

For one material, over one period:

Opening stock, plus receipts, less issues, equals closing book stock.

Count the material. The difference between that count and the closing book figure is the variance.

That is all the arithmetic there is. The difficulty is entirely in what the variance means and what you do with it.

Variance is a residual, and residuals absorb everything#

The variance is not a measurement of pilferage, or of wastage, or of anything else in particular. It is whatever is left over after every recorded event has been accounted for, which means it contains every unrecorded event of every kind:

• Issues that were never written down.
• Receipts posted at a wrong unit.
• Material returned to store and never entered.
• Material transferred to another site with no paperwork.
• Counting error, this time or last time.
• Damage and handling loss.
• Actual loss.

Six of those seven are recording problems. The seventh is the one everybody jumps to. If your issue register is incomplete — and on most sites it is, for the reasons set out in running a site store — then your variance is dominated by the first item on that list and tells you almost nothing about the last one.

So the first question about any variance is not where did it go. It is how good are the records this variance was computed from.

Count small, count often#

The standard practice is a full stocktake at long intervals. It is the worst possible design.

A quarterly count produces one large variance covering three months of transactions, thousands of entries and several changes of personnel. It is unexplainable by construction. So it gets written off with a generic reason, and the exercise teaches nobody anything.

Counting a few materials every week — perpetual inventory, cycle counting, whatever your organisation calls it — produces small variances covering a small number of entries. Those are traceable. Somebody can actually walk back through a week and find the issue that was not recorded.

The other advantage is unpredictability. A count everybody knows the date of is a count people prepare for.

Rank what to count by value at risk rather than by item count: quantity times rate times how easily the material moves. The top few materials on a construction site usually carry most of the exposure, and counting them monthly while counting the tail annually is a far better use of the same hours than counting everything quarterly.

The adjustment is an entry, not an edit#

When the count and the book disagree, the book has to move. How that happens decides whether the exercise was worth doing.

The wrong way is to correct the stock figure to match the count. The number changes, the difference disappears, and next quarter nobody can tell whether this material has needed adjusting every quarter for two years.

The right way is a dated adjustment entry, of a stated quantity, with a stated reason, attributed to a person, sitting in the ledger alongside every other movement. The balance ends up the same. The history does not.

This is the store's version of a rule we hold everywhere in our own systems: a correction is an entry, never an overwrite. A record that can be silently revised is a record that answers today's question and no other.

The pattern is the finding#

One variance is noise. Materials get miscounted, entries get missed, and a single number in a single month means very little.

What is worth acting on:

The same material, the same direction, repeatedly. That is a process fault — a conversion factor, a habitual unrecorded issue, a supplier who consistently delivers at one end of a tolerance.

Variance that appears after a change. A new storekeeper, a new site layout, a new material with an unfamiliar unit. The change is the explanation and the fix is training or design, not investigation.

Variance concentrated in one location while the same material is clean elsewhere. That narrows the question to a place and a group of people, which is the only situation in which the security conversation is well founded.

A variance that suddenly stops. Worth as much attention as one that starts.

None of those is visible in a single reconciliation. They are all visible in a year of small ones, which is the argument for frequency stated a different way.

Two things to stop doing#

Stop netting variances across materials. A shortfall of cement and a surplus of sand do not cancel. They are two separate facts and adding them produces a number with no meaning, which will nonetheless be reported.

Stop netting across periods. A shortfall one month and a surplus the next usually means a timing problem — an issue recorded in the wrong period, or a receipt posted late. That is worth knowing, and it disappears entirely if you only look at the cumulative figure.

What a good reconciliation produces#

Not a corrected balance. You would have got that from any adjustment.

A good reconciliation produces a short list of specific, dated, explained differences, and a shorter list of differences nobody can explain. The second list is the output, and it is one of the things that has to be settled before the books close — month-end at a builder's accounts desk. If it is empty every month, either your store is exceptionally well run or your counts are being reconciled to the book rather than the other way round, and it is worth knowing which.

The short version#

Book minus physical is a residual, and a residual contains every unrecorded event, not just the interesting one.

Count small, count often, adjust by entry rather than by edit, keep materials and periods separate, and look for repetition rather than magnitude.

The variance is a number. The pattern is the information.

The contractor does the work, the work is measured, a bill is certified — and then a stated percentage of the certified amount is held back by the employer rather than paid across. It accumulates through the project. It is released later, in stages, once the work is complete and once a defect liability period has passed without the work falling apart.

The percentage, the cap, the timing of release and the length of the defect period are all contractual. There is no universal figure, and anybody who quotes you one without reading the contract is guessing.

What it is for#

Two things, and they are different.

Security against defects. If something fails during the defect liability period and the contractor does not come back to fix it, the employer has money in hand to have it fixed by somebody else. That is the stated purpose and it is a reasonable one.

Leverage for completion. Retention gives the contractor a financial reason to finish properly and to attend to a snag list. It is the part everybody understands and nobody writes down.

Both are legitimate. It is worth knowing which one is actually operating in a given argument, because they resolve differently.

Why it is difficult to track#

Retention has an awkward shape for an accounting system.

It is not a discount — the contractor earned it and it is owed. It is not an outstanding invoice — nothing further needs to be billed. It is not a liability with a fixed date — the release date depends on completion, which is an event, not a calendar entry. And it accrues in small amounts across dozens of bills over years, so it is never a single number anybody set out to record.

The result is almost universal: retention lives in memory. The contractor knows roughly what they are owed. The employer knows roughly what they are holding. The two figures are different and neither is written anywhere as a total until somebody asks.

On the contractor's side this is money already earned and often already spent on the job that generated it, and a contractor who has not priced that wait into his rate is lending it — one of the layers in quoting a rate you can live with. On the employer's side it is a liability that does not appear anywhere obvious and then arrives all at once.

Making it a balance#

The design that works is to stop treating retention as a special case and treat it as a payment stage that has not fallen due yet.

That single move solves most of it. A payment schedule can already hold stages with amounts and dates. If a retention deduction is a stage on that schedule, marked as retention, with its date meaning the release date rather than the due date, then everything that already works for payment stages works for it: it shows up in a forward view of money owed, chasers chase it when the date nears, and releasing it is the ordinary act of marking a stage paid.

That is how we built it in our own system, and the reason we built it that way was to avoid inventing a second mechanism. A second mechanism means a second set of screens, a second set of rules, and a second place for the truth to live — which is the shape of problem described in a fact that had no owner, where the same question was being answered independently in nine places and the answers had drifted.

Alongside it sits the thing nobody had before: a register. Every vendor's held money, totalled in one place, sorted by release date, with past-due releases called out. Held money the company owes but is holding becomes a number anybody entitled to see it can read, rather than a memory distributed across a hundred task pages.

The questions a retention register has to answer#

If you are building or buying one, these are the questions. A system that cannot answer all five is not tracking retention, it is storing it.

1. How much are we holding in total, right now?
2. From whom, and against which contract?
3. When is each amount due for release, and on what event?
4. What has already been released, when, and who authorised it?
5. What is past its release date and still held?

The fifth one is the one that actually costs money, in both directions. Held money past its release date is money the other party is entitled to and is probably already unhappy about. From the employer's side it is a liability quietly ageing. From the contractor's side it is working capital sitting in somebody else's bank account.

Release is an event, not a date#

The most common error in a retention system is to store a release date and treat it as automatic.

Release is usually conditional: on practical completion, on a certificate, on the expiry of a defect period that itself starts from an event. Storing a date without storing what the date depends on means the date silently becomes wrong as soon as the programme moves — which on a construction project is immediately.

The workable arrangement is to store both: the condition in words, and the current expected date. When the condition is met, the date becomes real and the stage falls due. Until then the date is a forecast and should be shown as one.

This is a specific case of a general principle we keep returning to — the app should tell you why. A release date with no stated basis is a number people either trust wrongly or ignore entirely, and both are worse than a forecast that says what it is waiting for.

Retention against other deductions#

Retention is not the only thing withheld from a certified bill, and confusing the categories makes reconciliation impossible.

A bill may have retention held, plus statutory deductions, plus recovery of an advance, plus set-off for something the contractor owes, plus a deduction for work not accepted. These have completely different legal characters and completely different futures. Retention will be released. An advance recovery will not — it is repayment of money already paid. A deduction for short work is gone for good.

Lumping them into one "deductions" figure on a certificate is common and it destroys the ability to say what is owed to whom. Each needs its own line and its own running balance. The mechanics of one of them are set out in set-off.

The short version#

Retention is earned money, deliberately unpaid, held against a future condition.

The failure mode is not fraud. It is that nobody totals it, because it accrues in fragments and has no natural home in a ledger.

Give it a home — as a payment stage whose date is a release date — and it stops being a memory and starts being a balance.

The word doing all the work is running. An RA bill is not a bill for this month's work. It is a restatement of the entire job to date, from which everything already certified is subtracted.

That distinction is the source of most of the confusion around these documents, and it is worth being precise about, because the two framings produce different numbers as soon as anything is revised.

The shape of the arithmetic#

For each item in the bill of quantities:

• Cumulative quantity executed to date
• Times the agreed rate
• Equals cumulative value of that item

Sum across items to get gross cumulative value. Then, at the foot:

• Less cumulative value certified in previous bills
• Equals gross value of this bill
• Less retention on this bill
• Less recovery of advance
• Less statutory deductions
• Less any set-off
• Equals net payable now

Every line above the "less previous" is cumulative. Everything below it is about this payment.

Why cumulative rather than periodic#

Because measurement is not exact, and revision is normal.

Suppose last month you certified a quantity that turns out, on remeasurement, to have been overstated. Under a cumulative system, this month's bill simply shows the corrected cumulative figure; the "less previous" line does the rest, and the correction flows through automatically as a smaller payment now. No credit note, no negative bill, no argument about which month the error belongs to.

Under a periodic system you would need an adjustment entry against a closed period, and construction contracts generate enough of those to make it unworkable.

The cost of the cumulative approach is that everybody has to hold two numbers in their head for every line, and people routinely quote the wrong one.

Where cumulative bills break#

Item codes changing. The whole structure depends on this bill's item three being the same item as last bill's item three. Renumber the schedule midway — because scope was added, because somebody reorganised the spreadsheet — and every cumulative comparison silently becomes meaningless. The bill will still add up. It will just be adding up different things.

Rates changing. If a rate is revised, does the revision apply to work already certified at the old rate, or only to work going forward? Both are defensible, contracts say different things, and the answer must be decided once and recorded, because a cumulative structure applies the current rate to the cumulative quantity by default — which silently reprices work that was already paid for.

Variations and extra items. Work not in the original bill has to enter the structure somewhere. If it goes in as a lump sum at the bottom, it is outside the cumulative machinery and behaves periodically, and now the document has two different logics in it.

Negative movement. A cumulative quantity can go down. Most systems and most people handle this badly. A bill whose net comes out negative is arithmetically correct and organisationally impossible, and what usually happens is that somebody holds it back until the next bill covers it — at which point the records no longer describe events in the order they happened.

The deductions are not one thing#

The lines below the gross figure are usually collapsed into a single "deductions" total on the summary page. This is convenient and it destroys information.

Each deduction has a different future:

• Retention will be released later. It is a balance, and it needs a running total per contract. Its own mechanics are in retention money.
• Advance recovery is repayment of money already handed over. It reduces an outstanding balance which must reach zero by a defined point.
• Statutory deductions leave your hands entirely and are remitted elsewhere. They are not yours to negotiate about.
• Set-off is money the other party owes you being netted against money you owe them, and it has its own consequences — set-off covers them.
• Disallowance — work not accepted — reduces the contract value permanently and should say why.

Five different characters. If your certificate shows one number, then six months later nobody can reconstruct what was held and what was lost, and the final account becomes a negotiation about history rather than a calculation.

Certification is a separate act from billing#

A contractor submits. Somebody measures, checks and certifies. Those are different acts by different people, and an RA bill has three distinct quantities per line — claimed, measured, certified — which are not always the same.

Systems that store one quantity per line cannot represent a disagreement, which means the disagreement happens somewhere outside the system, usually in a meeting, and the record shows only the outcome. The contractor's file and the employer's file then contain different histories of the same project, and at final account time both are produced as evidence.

Storing all three costs one column. It is the cheapest dispute-avoidance measure available on a construction contract, and from the contractor's end it is also what stops a correct bill sitting unpaid — getting paid on time.

The final account#

Every RA bill is provisional. The final account is where the cumulative quantities become final, retention release begins, and everything held or disputed is settled.

The quality of that exercise is decided years earlier, by whether the interim bills kept their structure. A project whose item codes stayed constant, whose deductions were itemised, and whose claimed, measured and certified quantities were all recorded can produce a final account by arithmetic.

A project without those things produces one by negotiation, and negotiation favours whoever kept better records, which is a polite way of saying it favours whoever the other side cannot contradict.

The short version#

An RA bill restates the whole job and subtracts what was already certified. That is what makes corrections easy and what makes item codes sacred.

Keep the codes stable, keep the deductions itemised, record claimed and certified separately, and the final account becomes a calculation instead of an argument.

An advance payment is money paid before delivery for a specific supply. You pay part of the value of an order up front; the material arrives; the balance is paid. The advance is part of the price of that order and is consumed by it.

A mobilisation advance is a loan. It is given at the start of a contract so the contractor can establish the site, bring plant, hire people and buy material before any bill has been raised. It is not payment for anything. It is recovered from subsequent bills, usually as a percentage deduction from each, until the balance reaches zero.

The words are similar, the accounting is opposite, and the confusion is expensive.

Why the distinction matters in the ledger#

An advance payment against an order reduces the amount still owed on that order. If the order is worth a certain sum and part of it has been paid, the remaining liability is the difference. Straightforward.

A mobilisation advance creates a receivable — the contractor owes you that money back — while the contract liability remains the full contract value. Two separate balances, moving in opposite directions, over the life of a project.

Book a mobilisation advance as if it were an advance payment against the first bill and two things go wrong. The first bill appears largely settled when it is not. And the recovery schedule has no balance to work against, so it either never happens or happens by hand.

The reverse error is worse. Book an advance payment against an order as a recoverable advance and the vendor is eventually asked to repay money that was part of the price. That conversation goes badly and it is entirely your fault.

What a mobilisation advance needs#

A recovery mechanism, defined at the start. Usually a percentage of each interim certificate, sometimes with a holiday at the beginning and a requirement that recovery completes before a stated point in the programme. The mechanism must be in the contract and in the system, because a recovery percentage that lives only in the contract will be forgotten by whoever prepares the third bill.

A running balance visible on every bill. Advance given, recovered to date, outstanding. Printed on the certificate. This is one line and it removes an entire category of end-of-project surprise.

Security, and a date on the security. Advances are commonly backed by a bank guarantee. Guarantees expire. A guarantee that expires while a substantial advance is still outstanding is no security at all, and the expiry date is the kind of thing that is diarised once, by one person, who then changes job.

Interest terms, or an explicit statement that it is interest-free. It is a loan. Whether it carries interest is a commercial decision, and leaving it unstated means the answer is decided later by whoever argues better.

The recovery that stops halfway#

The common failure is not that recovery never starts. It is that it stops.

Recovery is a percentage of certified value. If certification slows — because the work slowed, or because a dispute paused billing — recovery slows with it. If the contract is terminated or the scope reduced, there may not be enough remaining certified value to recover the balance at all.

At that point you are an unsecured creditor for the outstanding advance, holding a guarantee which may or may not still be valid, in a relationship which by definition has already gone wrong.

The forward-looking version of this question — if everything stopped today, what would we be owed and what security do we hold — is one very few organisations can answer quickly, and it is the whole reason the outstanding balance needs to be a number on a screen rather than a figure in a file.

Where advances get paid twice#

The most direct way to lose money on advances is to pay one twice, and it happens through a mechanism that has nothing to do with carelessness.

An advance is paid. Later, the full order value comes up for payment, because the record of what is still owed was not reduced. Or a stage payment schedule is created after an advance has already gone out, and the schedule is written for the full amount.

We hit a version of this in our own software, from the other direction. A payment made in stages — an advance first, then the balance — never wrote the field that meant this is paid, because when a payment has a schedule the stages are the payment record. Every queue that asked "is the paid date set?" was blind to money that had moved in instalments, and a fully settled order kept appearing in the queue asking to be paid again. Nine separate screens were asking that stale question, each written by somebody who reasonably assumed the stamp meant what it looked like it meant. The full account is a fact that had no owner.

Nobody paid twice, because a person noticed. But the system was asking them to, repeatedly, and a system that repeatedly asks for something wrong eventually gets it.

Two rules that prevent most of it#

An advance must be attached to something. An order, a contract, a stage. Money that leaves the building against a vendor name and nothing else cannot be netted off later except by memory. The same rule governs the small sums a labour contractor draws mid-month against the next bill — paying a labour contractor.

The remaining balance must be computed, never stored as an independent number. Remaining equals agreed less everything recorded as paid, worked out by one piece of logic that every screen asks. The moment two places compute it separately they will disagree, and each will be internally consistent, so nobody will notice for months.

The short version#

An advance payment is part of a price. A mobilisation advance is a loan.

One is consumed by the delivery it belongs to. The other has to be recovered, tracked, secured, and shown as a balance on every certificate until it reaches zero.

Booking them the same way is not a bookkeeping preference. It is how money goes out twice and comes back once. The related question of what to do when a stage payment is short of what was agreed is covered in paying less than agreed.

A subcontractor has certified work worth a sum. They also damaged something, or were supplied material from your store, or were overpaid on a previous bill. So the certificate is reduced by that amount and the balance is paid.

It is quick, it is common, and it is often the right commercial answer. It also does something to your records that is worth understanding before it becomes routine.

Two obligations become one number#

Before set-off there are two facts: you owe them a certain amount for work done, and they owe you a certain amount for a specified reason.

After set-off there is one payment.

The two original facts still existed. But if the only entry in the system is the net payment, they are no longer recorded anywhere except in whatever note accompanied it. The certified value of the work is understated. The recovery is invisible. And the reason for the recovery — which is the only part anybody will want six months later — is nowhere at all.

Then somebody asks a perfectly ordinary question: how much have we certified on this contract to date? The answer from the ledger is wrong, low by the amount of every set-off ever applied — and on the other side it is an unexplained deduction, which is the commonest entry in when your ledger and theirs disagree.

The right shape#

Record both sides. Pay the net.

• Certify the work at its full measured value.
• Raise the counter-claim as its own entry, dated, with its own reason and its own authorisation.
• Show the payment as the certified value less that specific recovery, itemised.

Three entries instead of one. It costs a minute and it preserves the two facts that actually happened.

On a running account bill this matters even more than usual, because those bills are cumulative. A set-off buried in a net figure corrupts every subsequent cumulative comparison, and the corruption compounds silently across the project.

What makes set-off contentious#

The counter-claim is usually an assertion, not an agreed figure.

Damage to a wall is a fact. The cost of repairing it is a judgement. Material issued from your store is a fact; the rate at which it is charged back is a decision. When you set off, you are simultaneously deciding the amount and enforcing it, without the other party having agreed to either.

Legally the position varies with the contract and the circumstances, and it is not something to settle from an article. What is universally true is procedural: a set-off applied without notice, without a stated basis, and without a chance to respond is the single most reliable way to convert a commercial disagreement into a dispute, because it takes money out of somebody's hands before the argument has happened.

The practical rules that follow from that are unglamorous:

1. Notify before, not with, the payment. A deduction discovered on a remittance advice reads as a decision already taken.
2. State the basis in a sentence somebody can dispute. "Recovery: material issued from store, 14 items, list attached" can be argued about. "Recovery" cannot, so the argument becomes about the whole relationship instead.
3. Keep it separate from retention. Retention will come back. Retention money is a balance held against a future event; a set-off is gone. Lumping them into one deduction line means neither can be reconciled.

The reason is the record#

Once a set-off is applied, the reason for it becomes the only thing standing between you and a claim.

This is a specific case of something we keep running into in our own systems. When a payment is recorded for less than the agreed amount, our software now requires an explanation before it will accept the entry — the gap and its reason land on the record together, and the originally agreed figure stays reconstructible as paid plus deducted. That was built after we watched what happens when it is not there. The mechanics are in paying less than agreed.

We also refused, deliberately, to let anybody delete a payment schedule that contained written-off stages, because deleting it would take with it every recorded reason for the write-off — and those reasons are the only surviving answer to who decided that money would never come.

A deduction with a reason is a commercial position. A deduction without one is an unexplained shortfall, and unexplained shortfalls are what the other side's lawyer builds a case from.

Set-off across contracts#

The tempting extension is to net across relationships: they owe us on project A, so reduce their payment on project B.

Whether this is permitted is a contract question and often a legal one, and the answer is frequently no. Separate contracts are separate obligations, and sometimes separate legal entities are involved even when the same people are.

Beyond the legal position, it has a practical cost that people underestimate. Once amounts move between contracts, no single contract's account is self-contained. The cumulative figures on both projects are now wrong in opposite directions, the final accounts cannot be prepared independently, and tracing anything requires a person who remembers.

If it must be done, do it as two explicit transfers with a stated reason, so each contract's own account still tells the truth about that contract.

The short version#

Set-off is netting two obligations into one payment.

The payment is fine. The netting of the records is not, because it destroys both original facts and keeps neither reason.

Certify in full, raise the counter-claim as its own entry with its own basis, notify before you deduct, and never let a set-off share a line with retention.

It works perfectly for a bill that is paid in one movement, which is most bills. It fails completely for a bill paid in stages, which is most of the money. Staged payment is not an edge case in construction, because money arrives on one ladder and leaves on another — two payment ladders that never line up.

The structural problem#

When a payment has a schedule, the stages are the payment record.

An advance in August, a balance in September. Two entries on a schedule, each with an amount, a date and a reference. Between them they describe the whole payment. There is nothing missing and no information has been lost.

What has not happened is the writing of a single top-level paid date, because there is no single date to write. The payment did not happen on a day. It happened across two.

So a system carrying both mechanisms — a paid date for simple payments and a schedule for staged ones — has two representations of the same fact. And every piece of code in it must know which representation to ask.

They do not. Not because anybody is careless, but because the paid date is right there, obvious, well named, and correct for most rows, and the schedule requires you to know it exists.

What it looks like when it goes wrong#

This happened to us, and the shape of it is worth setting out because it is almost certainly happening somewhere in your own tools.

An order was paid in full — an advance, then the balance some weeks later. Every rupee had gone. The people who paid it knew it was paid.

A queue inside the software kept asking for it to be paid again.

The cause was exactly the structure above. The instalment function never wrote the top-level paid date, so any query asking is the paid date empty? was blind to every rupee that had ever moved in instalments. One screen asking the wrong question is an ordinary defect. What we found was the same question asked all over the application, place after place, each in its own words, each written by somebody who reasonably assumed the field meant what it looked like it meant.

Four of them were queues and counters: the list cleared to pay, the list waiting for a signature, the number in the sidebar, and the sweep that puts a decision back in front of somebody who has already made it. Five more were found afterwards.

The full account, including the automated test that was holding the bug in place, is in a fact that had no owner.

The three downstream failures#

The queue was the visible symptom. The expensive parts were downstream.

A chaser that had lost its credibility. A material line on an order paid in stages sat at "waiting on payment" for ever, and that stage has a reminder attached which rings the finance team every few days. So Finance was being reminded, repeatedly, about money that had already left the account.

Nobody reported it. That is the part worth sitting with. A recurring reminder which is occasionally wrong teaches you to skim the whole class of reminder, and once you skim it, the one that matters costs the same as the ones that do not.

A lorry that arrived unannounced. The same stale question was being asked at the gate. The guard's list of expected loads refuses any line whose money has not settled, which is sensible. A load paid to the last rupee in stages carried no paid date, never reached the list, and a fully-paid lorry turned up at the barrier with nobody expecting it. That is the exact event the screen exists to prevent.

A matcher that never let go. Our bank-line matcher kept staged-payment tasks in its candidate pool for ever, at their full amount, because the stages never set the paid date. So a long-settled order stayed permanently available to be matched against some future incoming transaction. The fix was to treat a fully answered schedule as a settlement timed at its last stage.

Three completely different subsystems. One missing fact.

The fix is not one fix per screen#

Writing the correct condition into each of those places would produce a copy of a rule per screen, which is the same problem again with a longer fuse.

There is now one function that answers has the money for this actually settled?, living in the file that owns payment schedules, with a mirror of it in the database query language beside it so the two cannot drift apart. Every surface asks it. None of them holds a second opinion.

That is the general remedy for this class, and it applies far beyond payments: any fact your work depends on that is computed in more than one place will eventually disagree with itself, and it will not disagree loudly. The same argument, applied to balances rather than to flags, is in retention money is a balance, not a memory.

What to check in your own system#

Take one order that was paid in two parts, and ask each of these questions of your software:

1. Does it appear as outstanding anywhere?
2. Does any reminder still fire for it?
3. If you export a list of unpaid bills, is it on it?
4. Does the ageing report include it?
5. If somebody searched for it today, would the answer be the same on every screen it appears on?

If the answers differ, you have the same structure, and the number of places it has leaked into will be larger than you expect. Ours was nine.

The design lesson#

Do not represent one fact two ways.

If staged payment is possible at all, then the schedule is the payment record and the top-level date is a derived convenience at best — and a derived convenience should be computed, not stored, because a stored one goes stale in silence.

And if you must have both, then no code anywhere should read the raw field. It should ask a single function, and that function should be the only thing in the system that knows both representations exist. Everything else asks it.

A fact worth trusting has one owner.

That decision looks like a single act and is really five comparisons, done in order, each of which can send the invoice back. Most organisations do two of them properly, skip one, and do the remaining two by feel.

The five comparisons#

1. Is this invoice ours at all? Correct legal entity, correct site, correct project. Multi-entity groups get this wrong constantly, and an invoice paid by the wrong entity is a tax problem as well as an accounting one.

2. Is it a duplicate? Same vendor, same invoice number, same amount. Also: same amount and same date with a different number, which is the version that gets through. Duplicate payment is one of the largest recoverable losses in any purchase ledger and it is caught by a check that takes a second.

3. Does it match the order? Rate, unit, terms, tax treatment. Compare the invoice against the purchase order, because the rate was agreed in advance and the delivery has no opinion about it.

4. Does it match the receipt? Quantity, against what your side recorded as arriving — not against what the order said, and not against the vendor's challan. This is the comparison that requires an independently written goods receipt note, and it is the one most often skipped.

5. Does the arithmetic work? Quantity times rate, plus tax, equals total. Invoices are typed by people.

Steps three and four together are three-way matching. Steps one, two and five are the ones nobody writes a procedure for and everybody assumes somebody else did.

Why the receipt comparison fails#

Not because people are lazy. Because of four ordinary situations that a simple one-to-one comparison cannot represent.

One order, several deliveries. Five lorries, five receipts, one monthly invoice. The comparison is many-to-one and a naive check either refuses it or compares against the first receipt and reports a shortfall that is not real.

One delivery, several orders. A vendor consolidates. The reverse.

Deliveries that straddle the period. Material received on the last day of the month, invoiced in the next. Nothing is wrong; the two documents simply live in different periods and any comparison restricted to a period misses them both.

Receipts recorded from the challan. If the receipt was written by copying the vendor's own document — which is fast, and common — then the comparison is between the vendor's number and the vendor's number. It always passes. It proves nothing.

The fourth is the serious one, because it is invisible. The other three cause visible friction and get fixed. This one produces a clean report.

The mismatch that is not a mismatch#

A large proportion of investigated mismatches turn out to be unit differences rather than quantity differences. Ordered per tonne, invoiced per quintal; received in bags, invoiced in kilograms.

The comparison must include the unit or it will confidently report a quantity discrepancy and send everybody looking in the wrong place. It has its own piece: the unit of measure.

Tax lines are part of the reconciliation#

The tax on an invoice is not decoration and should be checked against the order rather than accepted.

Two things to look at. Whether the tax treatment matches what was agreed — the place of supply, the rate category, whether the vendor is charging tax at all. And whether the invoice contains the details your own credit claim depends on: the vendor's registration, a valid invoice number, the correct particulars.

The reason this belongs in the reconciliation rather than later is that an invoice with defective particulars is easy to have corrected while the money is still unpaid and nearly impossible afterwards. The mechanism, and why the vendor's own filing behaviour becomes your problem, is in input tax credit.

What to do with a genuine mismatch#

Not hold the whole invoice indefinitely. That is the default behaviour and it is bad for everybody: the vendor is unpaid on the correct lines as well as the disputed one, the relationship deteriorates, and the disputed line gets settled under commercial pressure rather than on the facts.

Better: pay what is agreed, hold what is not, and say in one sentence what is held and why. A vendor who knows exactly which line is in question and why can resolve it. A vendor whose invoice is simply unpaid can only chase, which is the same five comparisons seen from the other end — getting paid on time, from the contractor's side.

And record the held amount as its own entry with its own reason, rather than paying a net figure and letting the difference vanish. That distinction — between netting the payment and netting the record — is covered in set-off.

Automate the comparison, not the decision#

The checking is arithmetic and belongs to a machine. There is no reason for a person to compare five hundred invoice lines against five hundred receipt lines.

The decision is different. Whether to pay an invoice with a small discrepancy, whether to accept an explanation, whether this vendor's pattern is worth a conversation — these need somebody who knows the relationship.

We hold to that separation firmly in our own systems: the machine proposes, a person decides. When our software matches a delivery document to a purchase, the match is recorded as a suggestion and only a person's tap makes it a link. When it suggests a bank transaction belongs to a particular order, that is an ask, not an attachment. The reasoning is in the machine proposes, a person decides.

It is not caution for its own sake. A machine that attaches money to the wrong order does not merely make an error — it makes an error that looks like a record, and the next person to read it has no way of knowing a human never agreed.

The short version#

An invoice is a claim. Five comparisons decide whether to honour it, and the one that matters most needs a receipt your own side wrote.

Check the entity, check for duplicates, match the rate to the order and the quantity to the receipt, and redo the arithmetic.

Then pay what is agreed, hold what is not, and say which is which.

The recipient has not lost that money. It sits to their credit and is set against their own tax liability when they file. What has changed is the timing and the identity of who hands it over.

This piece is about the mechanism and the errors it generates, not about rates, thresholds or section numbers. Those change, they depend on facts about the payee that only your accountant should be deciding, and getting them from an article is how people end up with demands. Take the numbers from your accountant. Take the shape from here.

Why the mechanism exists#

Collecting tax from a large number of small recipients is difficult. Collecting it from a smaller number of payers who are already keeping books is easier.

So the obligation is placed on the payer. And because the obligation is on the payer, the consequences of getting it wrong land on the payer too — which is the part that surprises people. If you fail to deduct when you should have, the shortfall, and interest on it, is generally recoverable from you, not from the person you paid.

That single fact explains why finance departments are cautious about this to a degree that looks disproportionate from outside.

The four decisions in every deduction#

Each payment requires four questions to be answered, in order, and each has its own failure mode.

Is this payment of a type that attracts deduction? Different categories — contract work, professional services, rent, commission, purchase of goods — have different treatments. Construction organisations pay all of these, often to the same vendor, sometimes on the same invoice.

Who is the payee, in tax terms? The treatment can depend on the legal status of the recipient and on whether they have furnished a valid tax identification. A missing or invalid identifier typically attracts a materially harsher treatment, which is why collecting and verifying it before the first payment matters far more than it seems to at the time.

On what amount? Generally the value of the service, and whether tax charged on the invoice forms part of the base depends on how the invoice is drawn and on the category. An invoice that does not separate the components makes this question harder than it needs to be.

When? Deduction obligations are usually triggered at the earlier of credit in the books or payment. This catches people who assume nothing happens until money moves. A provision made at year end can trigger the obligation without anybody writing a cheque.

Where construction makes it harder#

Mixed invoices. A single bill for material supplied and labour to install it may attract different treatment on different components. If the invoice shows one figure, somebody has to apportion, and an apportionment done by guesswork is a decision made by the least qualified person in the chain.

Running account bills. These are cumulative — each restates the job to date and subtracts what was already certified. Deduction is on this bill's payment, not on the cumulative figure, and a system that applies a percentage to the wrong one over-deducts spectacularly. The cumulative structure is set out in running account bills.

Advances. Money paid before work is done can still trigger an obligation depending on the category and the terms. A mobilisation advance, being a loan rather than a payment for services, may be treated differently from an advance against an order — one more reason to book the two distinctly.

Retention. Money withheld and released later raises a timing question that is easy to get wrong in both directions: deducting twice, or never deducting at all because the release looks like a balance movement rather than a payment.

Set-off. When a payment is netted against a counter-claim, the deduction base is the gross amount, not the net you actually pay. Systems that compute deduction from the payment figure get this wrong every time. It is another reason to record gross and recovery separately rather than paying a net number, which is the argument made in set-off.

The certificate is the point#

The recipient can only claim credit for what has actually been deposited and reported against their identifier. So three things have to happen, not one: deduct, deposit on time, and report correctly in the periodic return.

A deduction that is made but not reported is worse than no deduction at all from the payee's point of view: their money has gone and they cannot claim it. This is a very common cause of vendor disputes, and it is invariably discovered months later when the vendor's own filing does not reconcile.

Two practical consequences:

• The vendor's tax identifier is a critical data field. It should be validated when the vendor is created, not when the first payment is made, and a change to it should be treated as significant rather than as an ordinary edit.
• The mapping from payment to identifier must be exact. Paying one legal entity and reporting against another's identifier produces a credit that lands in the wrong account, and unwinding it is slow.

What a system should and should not do#

It should compute the deduction, using rates held as configuration rather than in code, per category and per payee status. It should show gross, deduction and net separately on every payment record. It should make the deduction reconstructible: which rule was applied, on what base, on what date.

It should not decide the category. That is a judgement about the nature of the work, and a machine which quietly categorises payments is making tax decisions in the dark. The right shape is the one we use for everything of this kind — the system proposes a treatment with its reasoning visible and a person confirms. The argument for that is in the machine proposes, a person decides.

The short version#

Deduction moves a slice of a payment to the government on the payee's behalf, and the obligation — and the liability for getting it wrong — sits with the payer.

Four questions per payment: what type, who is the payee, on what base, and when. Construction complicates all four because of mixed invoices, cumulative bills, advances, retention and set-off.

And the deduction is only half the job. Depositing and reporting it correctly is what turns a withholding into a credit the vendor can actually use.

The intent is that tax falls on value added rather than accumulating at every handover. The mechanism is straightforward. The conditions attached to it are where construction organisations lose money, and they lose it for reasons that have very little to do with tax and everything to do with record keeping.

As with anything of this kind: the rates, the categories and the boundaries are your accountant's territory. What follows is the shape of the mechanism and the operational habits it demands.

The conditions, in outline#

Credit is not automatic on having paid tax. Broadly, a set of conditions has to be satisfied: you must hold a valid tax invoice or equivalent document, the goods or services must actually have been received, the tax must have been paid to the government by the supplier, and you must have accounted for it in your own return within the applicable time limits.

Two of those four are outside your control, and one is entirely in somebody else's hands.

The condition that makes it operational#

The supplier must have declared and paid.

This is the one that changes how a purchase department has to behave. Your credit depends on a third party filing their return correctly, on time, with your registration correctly stated on the right invoice.

If they do not, your credit is at risk regardless of the fact that you paid them the tax in good faith. The recovery route is commercial — you chase the supplier — and the commercial leverage you have is whatever money of theirs you are still holding.

Which produces the single most useful operational rule in this area: the tax component of an invoice is not the same kind of money as the rest of it, and it is worth knowing whether the supplier has filed before the last payment goes out. Once you have paid in full, the leverage is gone and you are relying on goodwill.

Reconciliation is a monthly discipline, not an annual one#

Your books say you have a certain amount of credit. The tax system says your suppliers have declared a certain amount against your registration. These two figures will differ.

Every difference falls into one of a small number of categories:

• Timing. They filed in a later period than you booked. Resolves itself.
• Your error. Wrong registration captured, invoice booked twice, credit claimed on something ineligible.
• Their error. Your registration typed wrongly, invoice reported against another customer, invoice not reported at all.
• Their failure. They have not filed.

Only the last two require chasing, and you cannot tell them apart from a total. This is exactly the argument for reconciling monthly rather than at year end: a small difference over one period is traceable to specific invoices, and a large one over a year is a project. Classifying every difference by cause is also what settles a plain balance confirmation — when your ledger and theirs disagree.

It is the same argument, structurally, as the one for counting stock small and often. A residual computed over a long period absorbs every kind of error and identifies none of them.

The restriction construction has to know about#

There are categories of expenditure on which credit is blocked, and one of them matters enormously in this industry: credit relating to the construction of immovable property is restricted in defined circumstances.

The precise boundary — what counts as construction, what counts as plant and machinery, what happens when the property is built for sale rather than for own use, what happens with works contract services — is genuinely complicated, has been litigated, and is not something to determine from a blog post.

What every purchase and accounts person in construction should know is simply that the restriction exists and is expensive, and that assuming credit is available on everything is the single most costly wrong assumption in the area. Get the position for your own circumstances from your accountant, in writing, and then encode it in how purchases are categorised at entry rather than discovering it at filing time.

What this demands of the purchase process#

The tax conditions convert several things that look like clerical details into material controls.

Vendor registration details, validated at creation. Not at first payment. An invoice from a vendor whose registration was never verified is a credit you may not be able to claim, and it is far easier to fix before any money has moved.

Correct particulars on the invoice. Registration numbers, invoice number and date, place of supply, description, rate and amount of tax. An invoice with defective particulars can usually be replaced while it is unpaid. Afterwards it becomes a favour you are asking.

The receipt of goods, recorded. One of the conditions is that the goods or services were actually received. A purchase ledger that cannot demonstrate receipt independently of the vendor's own paperwork is weaker on this than it looks, which is one more argument for goods receipt notes written by your own side.

Time limits observed. Credit has to be claimed within a period. An invoice that surfaces late — found in a drawer, or held back during a dispute — can become a credit you are no longer entitled to. A dispute that drags is therefore not cost-free even if you eventually win it.

Where the checking belongs#

The comparison between your ledger and what suppliers have reported is arithmetic across two datasets and belongs to a machine.

The decisions that come out of it do not. Whether to hold a payment because a supplier has not filed, whether a difference is worth pursuing, whether a relationship is worth the friction — those need somebody who knows the vendor.

The right arrangement is the one we hold to throughout our own systems: the machine produces a list of specific, evidenced differences and proposes what each one probably is; a person decides what to do about it. Not because machines are unreliable, but because a machine that acts on its own leaves behind a record that looks like a human decision and was not. The reasoning is in the machine proposes, a person decides.

The short version#

Input tax credit offsets tax paid on purchases against tax collected on sales, subject to conditions — and one of those conditions is that somebody else filed their return properly.

That makes vendor data quality, invoice particulars and monthly reconciliation into finance controls rather than clerical work.

And in construction there is a restriction on credit relating to immovable property that is large enough to change project economics. Find out where the line falls for your own circumstances before you assume which side of it you are on.

This happens all the time, for good reasons: short quantity, damaged material, a rate correction, a recovery, an agreed discount for late delivery. It is ordinary commercial life.

What is not ordinary is what most systems do with it, which is accept the smaller number and say nothing. The result is a record showing an agreed amount and a paid amount that do not match, with no explanation attached to either, and a permanent open balance that nobody can close because nobody can remember why it is there.

The two readings of an unexplained gap#

Six weeks later somebody looks at that order. The agreed figure is one number, the paid figure is smaller. There are exactly two possible readings and no way to distinguish them:

• We still owe the difference. Somebody must chase it, and the vendor is right to be waiting.
• We settled for less, deliberately. The difference is not owed, the order is complete, and chasing it will be embarrassing.

Both readings are consistent with the record. Whichever one the reader assumes becomes the truth, and different readers assume differently.

That is the actual cost of a silent short payment. Not the money — the money was correct. The cost is a record that cannot answer a question about itself. It is also the commonest reason a vendor's ledger and yours will not agree — when your ledger and theirs disagree.

Ask at the moment, because it is the only moment#

The information exists exactly once: when the person entering the payment knows why it is short. Ten minutes later it is in their head, next week it is gone, next month they have left.

So the intervention has to happen at entry. In our own system, recording a stage payment below the agreed figure now asks why less before it accepts. It is one field and it is required.

Three things then happen with the answer.

The gap and its reason land on the stage row itself — an amount deducted and a short phrase saying what for. Not in a comment, not in an attachment: on the row, where anybody reading the payment reads the reason at the same time.

The order total revises to what was actually paid. Said out loud in a comment on the task and written to the audit trail, under the name of the person who did it.

The originally agreed figure stays reconstructible. Paid plus deducted equals what was agreed. Nothing is destroyed — the revision is a derived view, not an overwrite, which matters for the reasons set out in append-only records.

Why the total should self-correct#

This was the part that took an argument.

The instinct is to leave the agreed total alone, on the grounds that it is what was agreed. The problem is that everything downstream then reports a permanent shortfall on an order that is in fact complete: the outstanding balance is overstated, the ageing report shows an old open item, and any queue built on "agreed minus paid" carries it for ever.

So the rule we settled on is that the moment a payment schedule's last stage is paid or written off, the order total corrects to what the stages actually recorded — with an audit entry always, and a comment naming the person. And a sweep does the same for every order settled before the rule existed, converging to zero writes once history has caught up.

There is one deliberate exception. A correction of this kind does not void management signatures on the order. The rule that protects signatures exists for money still to move; this is money that already moved, and it moved downward of what was signed for. Voiding an approval because less was spent would be a machine punishing the right outcome.

Short payment is not the same as a deduction, or a write-off#

Three things look similar on a bank statement and are completely different in the ledger.

A short payment is the whole payment for that stage, at a revised amount, by agreement. The balance is not owed.

A set-off is a full payment reduced by a separate obligation running the other way. The full amount is still owed on this contract, and a counter-claim exists on its own account. Netting the two into one number destroys both facts — that is the subject of set-off.

A write-off is a decision that money owed will never arrive. It is not a payment at all. It has its own piece: writing off money that is never coming.

If your system offers one field for all three, it will be used for all three, and the ledger will lose the distinction permanently.

The reason has to be defensible, not free text#

A reason field accepting anything will receive "adjustment", "as discussed" and a single full stop.

Two things help. A short list of the reasons that actually occur — short quantity, quality deduction, rate correction, agreed discount, recovery — so the common case is a tap rather than typing. And a free field beside it for the specifics, because the list will never cover everything and forcing a category onto an unusual case produces a wrong category rather than a blank one.

The categories are what make the pattern visible later: one vendor consistently short-delivering, one material consistently disputed. A pile of free text cannot be counted, and a pattern you cannot count is a pattern nobody will find.

The general shape#

Any time your system accepts a number different from the number it expected, it is watching a decision being made and choosing not to record it.

That is the moment to ask. Not with a warning that can be dismissed, and not with a block — the payment is legitimate and blocking it teaches people to route around the system. Ask for the one piece of information that only exists right now, put it on the record beside the number it explains, and let the arithmetic reconcile itself.

A difference with a reason is information. A difference absorbed in silence is a question your records will be asked and cannot answer.

Stated like that it sounds too obvious to write down, and yet the two documents are routinely used interchangeably, produced from the same template, and approved by the same person on the same screen. They carry different risk, need different measurement, and pay out on different events.

What changes when you buy work rather than goods#

Completion is a judgement. A purchase order is satisfied by delivery, which is an observable event with a lorry attached. A work order is satisfied by work being done to a standard, and somebody has to decide whether it has been.

Quantity is measured after the fact. With goods, the quantity is what was ordered and what arrived. With work, the quantity is what was executed, and it is determined by measurement on site against the rates in the order — which is why work is paid on running account bills and goods are usually paid on invoice.

Defects appear later. Faulty material shows up on arrival or shortly after. Faulty work shows up in the monsoon. Hence defect liability periods and retention, neither of which has an equivalent in a straightforward purchase.

People are on your site. Which brings safety obligations, access control, insurance, and a set of statutory responsibilities that buying a lorry of sand does not.

The tax treatment differs, in ways that depend on the nature of the supply. This is your accountant's question, not a template's, but it is one more reason the two documents should not be produced by the same form with a different title.

The hybrid, which is most of them#

Very few orders in construction are pure. "Supply and fix", "provide and lay", "supply, install and commission" — these are a supply and a service in one line, and the split between them is not stated anywhere.

That unstated split is where several separate problems originate:

• Measurement. Is the item paid on delivery of material, on completion of installation, or partly on each?
• Risk of loss. Who owns the material sitting on site before it is fixed?
• Retention. Does it apply to the whole value or only the labour portion?
• Tax. The treatment may differ across the components.
• Defect liability. Material defects and workmanship defects may be different parties' problem.

None of these has a universal answer. All of them have an answer for your contract, and that answer should be written on the order rather than established by argument at the first dispute.

The line item is the contract#

Whichever document it is, its power sits in the description of each line, and descriptions are written badly with remarkable consistency.

A good line names: what is included, what is excluded, the unit, the rate, and what event makes it payable. That last one is the field almost nobody has, and it is the one that determines when money moves. The other clauses worth reading before anybody signs are set out in what a work order should say.

The habit of reading a description for what it excludes rather than what it includes is the same discipline that makes somebody good at reading a bill of quantities, and it is worth training deliberately.

Approval is about consequence, not amount#

Most organisations route approval by value: below a figure one person signs, above it two.

Value is a poor proxy on its own. A small work order that puts people on a live site, or that touches a structural element, or that commits you to a defect liability for years, carries more consequence than a large order for a commodity material at a rate already agreed.

A better shape is to route on the properties that actually create exposure: whether it is work or supply, whether it involves people on site, whether it creates an ongoing liability, whether the rate is pre-agreed or new. Value remains one input among several.

What should never vary is the floor. Money leaving the company needs two different people, regardless of amount, for reasons set out in why one person should never move the company's money.

Amendments, and the version that was actually acted on#

Orders change. Scope is added, rates are revised, quantities move.

The failure is not amendment. It is amendment by conversation. A revised rate agreed on a phone call, confirmed by a message, and never reflected in the order produces a document that no longer describes the agreement, and every downstream check against it fails correctly and inexplicably.

Two requirements. An amendment is a new version with a number and a date, not an edit to the original — because the original may already have been acted on and somebody may need to know what it said at the time. And the version that was current when each delivery or measurement happened must be identifiable afterwards.

This is the same principle that makes a signed document worth signing. The value of a record is that it says what it said; a record which can be revised in place is worth exactly as much as the memory of the last person to open it. We have written about the mechanics of that in tamper-evident documents.

The document that gets acted on is the one on the site#

A last practical point that no template solves.

The version of the order that governs behaviour is whichever version the person doing the work is holding. If that is a printout from three weeks ago, then three weeks ago is your contract, whatever the file server says.

The only real remedy is that the current version has to be easier to reach than the old one. Not a policy about superseded copies. A link that is genuinely faster to open than a piece of paper is to find, on a phone, on site, on a bad connection.

The short version#

A purchase order buys a thing and is satisfied by delivery. A work order buys an outcome and is satisfied by judgement, measurement, and eventually by the absence of defects.

Most real orders are both, and the split between the two halves should be written down rather than assumed.

Route approval on consequence rather than on amount alone, amend by versioning rather than by editing, and make the current version the easiest one to find.

It is an old rule, it is not clever, and almost every organisation that has one has spent years slowly weakening it — not by decision, but by a series of individually reasonable conveniences.

What the rule is actually protecting against#

Not primarily theft. Theft is the case everybody cites and the least common one.

The rule protects against three things, and the first two are much more likely than the third.

Error. Wrong vendor selected from a list, wrong amount typed, wrong invoice attached, payment made twice. A second person looking at the same payment catches a meaningful proportion of these, because they are reading it fresh rather than checking their own work.

Pressure. A person being leaned on — by a vendor, by a senior colleague, by circumstances — is much harder to lean on when the payment requires somebody else too. The rule does not just detect wrongdoing; it gives an honest person a reason they can say out loud.

Deliberate misuse. Rarer, and the reason the rule is written down.

The first two are why the rule earns its keep on a normal day, and it is worth saying so, because a control justified only by suspicion is a control people resent.

The conveniences that dissolve it#

None of these is proposed in bad faith. Each is proposed by somebody trying to make a real problem go away.

Amount bands. "Payments below a certain figure only need one signature." This is the most common and the most damaging, because it does not weaken the rule — it repeals it. There is now a size of payment one person can make alone, and a person intending misuse will simply make several. When this was proposed in our own system, we built everything else in that release and left this half out, on the grounds that a floor with a hole in it is not a floor.

Standing approvals. "This vendor is approved, so payments to them do not need a second look." The second signature is not about the vendor's legitimacy. It is about this payment.

Emergency overrides. Necessary, and the correct design is not to remove them but to make them loud: a named person, a stated reason, recorded distinctly, and visible afterwards without anybody having to go looking. An override that is quiet becomes an ordinary route within a month.

Delegation done carelessly. Somebody is travelling and hands their authority to a colleague — who already holds the other signature. Two slots, one human, and the rule is gone while the screen still shows two names.

Each of the four is a question worth putting to a vendor before you buy — approval chains worth asking about.

Delegation without collapsing the floor#

Delegation is genuinely necessary. People travel, take leave, fall ill, and a payment system that stops when one person is unavailable will be routed around.

The version that works has four properties:

• Bounded in time. A window with an end date, not an open-ended transfer.
• Revocable by either party, immediately.
• Never to somebody who already holds the other slot. One human must not end up holding two signatures, and this has to be enforced by the system rather than by the good sense of whoever sets it up.
• Visible on the record. The audit says on behalf of, and the person being stood in for is told when it is arranged.

The emergency override, if you have one, stays with the original holder. A stand-in gets the ordinary authority, not the exceptional one.

That is how we built it, and the constraint that shaped every part of it was the same sentence: two different humans sign every payment, and the floor never moves.

The second signature has to be a real reading#

A control that everybody performs and nobody exercises is worse than no control, because it produces a record of scrutiny that did not happen.

The second signature stops being real when the queue is full of items that require no thought. Approve forty routine payments and the forty-first gets the same reflex. This is not a character flaw; it is what attention does.

So the design job is to keep the queue about decisions. Three things help:

Only ask about money that has not yet moved. A queue that includes payments already made is asking for a decision that cannot be made — the money is gone — and it teaches people the queue is decorative. We had exactly this fault: a fix in one place caused every already-paid item to appear in the approvals queue asking to be signed, some of them weeks old. Money that moved without a sign-off has not been forgotten, but it belongs in its own place, where the question is who authorised this rather than shall we.

Put the facts that decide it on the row. Whether material has arrived against this payment, whether it is an advance, what the order was for. Our approvals queue says either that delivery documents have been filed or, in amber, that none have — money before material? A question, not a block, since some payments rightly precede material.

Say what is unusual. A signer's attention should be spent on the exceptional row, which means the system has to know which row is exceptional and say so. The general form of that argument is in an alert that rings for everything.

The record is half the control#

A signature that leaves no durable trace protects nobody, including the person who gave it.

What has to survive: who signed, when, on what basis, on which version of the document, and — where a delegation was used — for whom. That record must be one that cannot be quietly revised afterwards, which is the whole subject of what an audit trail is for.

And the record should protect the approver as much as the company. A person who signed something correctly, on the information available at the time, should be able to demonstrate that years later. That is not a side benefit. It is a large part of why people are willing to sign at all.

The short version#

Two different people on every payment, with no amount below which the rule lapses.

Delegate in bounded, revocable windows that can never put both signatures in one pair of hands. Make overrides loud rather than removing them. Keep the queue about money that has not yet moved, so the second reading stays a real one.

Every erosion of this arrives as a convenience, and each one is reasonable on its own. That is precisely why the floor has to be stated as a floor.

This is not a bad practice to be eliminated. It is the market. The problem is not that money goes first — it is that the record of a payment usually does not say whether it went first, and by the time anybody asks, the two cases look identical.

For a developer it compounds, because money leaves on the contractor's ladder before it arrives on the buyer's — two payment ladders that never line up.

The two payments that look the same#

Payment A: material was delivered, checked and received; the invoice was matched; the money went out afterwards.

Payment B: money went out so that material would be dispatched; nothing has arrived yet.

On a bank statement these are the same event. In most purchase ledgers they are the same event. And the difference between them is the entire risk position of the company: in the first case you have the goods, in the second you have a promise.

An organisation that cannot separate these cannot answer the only question that matters in a bad week — how much have we paid for material we do not yet have?

Asking at the moment of signature#

The moment to establish this is when somebody is authorising the payment, because that is the only moment when a person is looking at it who knows the answer.

In our own approvals queue, every payment awaiting signature now says one of two things: that delivery documents have been filed against it, or, in amber, that none have — no delivery challan yet — money before material?

It is a question, not a block. That distinction was deliberate and it is the part worth copying. A hard rule refusing payment without a delivery record would be wrong on a large fraction of legitimate purchases, and a rule that is wrong that often teaches people to find the override. Once the override is routine you have neither a rule nor a question.

What the question does is make the signer aware that they are making a choice rather than having one made for them. Some payments rightly precede material. The person signing is entitled to know which kind this is.

Why the question was harder to build than it looks#

The obvious implementation is to ask whether any delivery document is attached to this order. Ours did that, and for a long time it was structurally incapable of ever saying yes.

The document matcher only offered a delivery record against purchases that had not been paid. But in our process payment usually precedes dispatch. So by the time material arrived and somebody photographed the slip, the correct purchase was always in the paid state and was therefore never a candidate. The document matched nothing, and a document matched to nothing appears on no screen at all.

Every payment showed no delivery challan yet, permanently, including the ones where material had arrived weeks earlier and been photographed properly. An amber warning that is always on is not a warning. It is wallpaper, and within a fortnight nobody sees it.

The fix was one sentence: paid purchases are offered the match too, closed ones still are not — a closed order being the real test of a finished purchase. The general lesson is more useful than the fix. A check that cannot ever pass is worse than no check, because it consumes the attention a real warning would have needed.

What has to be recorded#

Four fields turn a payment into something you can reason about later.

Its type. Advance against order, payment on delivery, stage payment, retention release, mobilisation advance. These have different futures and different recovery mechanics — the difference between the last two is set out in a mobilisation advance is not an advance payment.

What it is against. An order, a contract, a stage. A payment attached only to a vendor name cannot be reconciled against anything.

Whether material has been received against it, as a fact that updates when material arrives, not a checkbox somebody ticks at payment time.

What was expected in return, and by when. Without this, an advance that is never fulfilled simply ages quietly. With it, the gap between the payment and the expected delivery becomes a date that can be chased.

The exposure report nobody has#

Given those four fields, one report becomes possible, and it is the point of the whole exercise:

Money paid, against material not yet received, by vendor, by age.

Almost nobody can produce this. It is the clearest statement of counterparty exposure a construction business has, and it is usually reconstructible only by a person going through orders one at a time.

Ageing matters as much as the total. An advance a week old is normal trading. The same advance six months old, to a vendor who has gone quiet, is a different kind of number, and it is exactly the kind that surfaces at year end when somebody asks why an order is still open.

Advances and the signature that follows them#

There is a sequencing trap worth naming.

If money goes out before the order is fully approved — because a supplier demanded payment to hold a rate, because somebody was on site and made a decision — then the approval that follows is a formality applied to a fact. Everybody involved knows the signature cannot change anything.

That situation should be recorded as what it is: money that moved without a prior sign-off, in its own list, where the question is who authorised this rather than shall we. Putting it into the ordinary approvals queue is worse than useless — it fills the queue with decisions that cannot be made and trains signers to click through. The argument about keeping an approvals queue about live decisions is in why one person should never move the company's money.

The short version#

Paying before delivery is ordinary in construction. Failing to record which payments those were is not.

Mark the type at payment, attach it to an order, let the delivery record update the position when material actually arrives, and put the question in front of the person signing — as a question, because a block would be wrong too often to survive.

Then you can answer the one question a purchase ledger is really for: what have we paid for that we do not yet have. The mechanics of matching an arriving delivery back to the payment it belongs to are in three-way matching.

Somewhere in your records is the thing that line paid for. Connecting the two is bank reconciliation, and although it is treated as clerical work, it is mostly inference — which means it can be wrong, and being wrong has consequences that outlive the mistake.

What evidence actually exists#

Four kinds, of very different quality.

An exact amount match. Strong, when amounts are distinctive. Weak when they are round numbers, because round numbers recur.

A reference in the narration. The strongest evidence there is, when it exists. It usually does not, or it exists in a mangled form. Receipts from flat buyers are the same problem in bulk, arriving against a reference printed on the demand letter and almost never quoted back.

A name in the narration. Good, if you can map bank narration strings to your vendors. Those strings are inconsistent, abbreviated and occasionally belong to a payment processor rather than the vendor.

Timing and recency. The weakest. Everything that happened this week is temporally close to everything else that happened this week.

The failure mode is treating a weak signal as sufficient because no strong one is available.

The near-miss amount#

We built a matcher that got this wrong, in a way worth describing because the mistake is so natural.

A transfer came in at an amount close to — but not equal to — the amount outstanding on a particular order. The matcher proposed the two as a pair, on nothing but that closeness. Its own explanation for the proposal read, in effect, no name, but the amount is close.

Close amounts are extremely common. Any organisation with a few hundred open items has several within a few per cent of any given figure, and a rule that accepts closeness will pair transactions with orders that have nothing to do with each other.

The rule now is that a near-miss amount alone is not evidence. It needs something beside it — a vendor name in the narration, a known alias, a label learnt from a previous confirmed match. An exact match still stands on its own, and so does an amount that reconciles arithmetically with tax added, because that is a computed relationship rather than a coincidence.

The general principle: closeness is not evidence, it is an absence of contradiction. Those feel similar and are not remotely the same thing.

The candidate pool that never emptied#

The second fault we found was subtler and had been quietly poisoning matches for months.

A payment made in stages never set the field meaning this is paid, because when a payment has a schedule, the stages are the payment record. So a fully settled order stayed in the matcher's candidate pool for ever, at its full original amount, permanently available to be matched against some future transaction that happened to be near it.

The pool was not a list of things awaiting payment. It was a list of everything that had ever awaited payment, and it grew without limit.

The correction was to treat a fully answered schedule as a settlement timed at its last stage, kept in the pool only through the same short proof window a hand-marked payment gets, and to make "remaining" actually subtract the advance. The same missing fact had leaked into eight other places in the application; the whole account is a fact that had no owner, and the version of it aimed at accounting systems is why staged payments break accounting systems.

Never attach on the machine's own authority#

This is the rule we hold to hardest, and it came from the owner of the business rather than from the engineering side: never auto-link anything.

A machine match is recorded as a suggestion. It carries its score and its reasoning. A person taps to confirm or to reject, and both answers are permanent — a rejection is remembered so the same wrong pair is never proposed again.

The reason is not that machines are unreliable. It is that an automatic attachment leaves behind a record indistinguishable from a human decision. Six months later somebody reads "this transaction paid that invoice" and has no way of knowing that nobody ever agreed. The error is not the wrong pairing; it is the false confidence in the record afterwards. That argument, in full, is the machine proposes, a person decides.

When we adopted this rule we also had to convert matches the machine had already made on its own authority back into suggestions, in the same migration that introduced the rule. There is no honest alternative: a record created by a mechanism you have since decided was not trustworthy does not become trustworthy by being old.

The evidence floor has to be everywhere#

A subtlety that cost us a round of fixes: it is not enough for the main matcher to have a high evidence standard.

The same suggestions appeared in a second place — a per-row list on the money page — and that list had been written separately, with its own scoring, at a lower threshold. So a pairing the main matcher would have refused was being offered as a one-tap action somewhere else in the application.

One rule, one implementation, asked by every surface. Two implementations of the same rule will diverge, and the divergence is silent because each is internally consistent.

Undo must be complete#

When somebody attaches a transaction and then undoes it, the undo has to clear everything the attachment created: the comment, the notification, and the open suggestion it answered.

We found that a stale suggestion card kept rendering on a task the money had never belonged to, because undoing the attachment did not close the question that prompted it. Half-undone states are worse than either the original error or a clean reversal, because they present as current information.

What a good matcher looks like#

• Exact matches, proposed with high confidence, still confirmed by a person.
• Near matches, proposed only with corroborating evidence, with the reasoning shown.
• No proposal at all where the evidence floor is not met — an honest empty result rather than a weak guess.
• Rejections remembered permanently.
• One implementation of the rule, asked by every screen.
• Complete undo.

None of that is clever. All of it is the difference between a reconciliation that saves work and one that creates a category of quiet error nobody can find later.

The short version#

Matching a bank line is inference from weak evidence. Amount closeness is not evidence. A candidate pool that never empties will eventually match something wrongly.

And whatever the machine concludes, a person taps. The cost of an automatic wrong link is not the link. It is that it looks like somebody decided.

The number changes and the ledger balances. That part is easy. What matters about a write-off is not the arithmetic at all — it is that a person made a judgement, and the judgement is the thing worth keeping.

A write-off is not a correction#

Three operations look similar on a balance and are completely different in character:

A correction fixes something that was recorded wrongly. The balance was never real. There is a right answer and you are moving to it.

A short payment settles for less by agreement. The balance is not owed because both parties said so. Its mechanics are in paying less than agreed.

A write-off accepts that a real, valid balance will not be collected or paid. Nothing was wrong. Somebody has decided to stop pursuing it.

Only the third involves a judgement about the future, and only the third carries a reason that somebody may need to defend. Systems that offer one mechanism for all three end up with a ledger in which nobody can tell an error from a decision.

Who is allowed to decide#

Writing off is giving up money. It should sit at least as high in the authority structure as spending the same amount, and frequently it does not — because spending has a form and a queue, while writing off is often just an edit on a screen.

Two properties are worth insisting on.

Authority proportional to amount, like any other financial decision. If two people are needed to pay a sum, two people should be needed to abandon the same sum. The reasoning behind that floor is in why one person should never move the company's money.

Never available to the person whose performance the balance reflects. Somebody responsible for collection should not be able to make an uncollectible balance disappear, for the ordinary reason that it removes the evidence of the thing they are measured on.

The reason is the record#

Once a balance is written off, the only surviving trace of the whole episode is whatever reason was recorded.

That reason has to answer three questions asked later, usually by an auditor, occasionally by a court:

• Why was it not collectible? Vendor dissolved, dispute settled, cost of pursuit exceeded the amount, work never accepted.
• What was attempted first? A write-off with no history of pursuit looks very different from one following a documented sequence of chasing.
• Who decided, and when?

"Adjustment" answers none of these, and "adjustment" is what a free-text field with no guidance receives.

We refused, in our own system, to allow a payment schedule containing written-off stages to be deleted. Deleting it would have been convenient — the schedule was cluttering a page — and it would have taken with it every recorded reason for every write-off on it. Those reasons are the only surviving answer to who decided the money would never come. The refusal is deliberate and it occasionally annoys people, which is roughly the right outcome for a control.

The write-off that races a payment#

A small technical failure with a large consequence, and it is worth understanding because the shape recurs everywhere.

Our write-off routine read the record, confirmed it was not paid, and then wrote the write-off. Two separate steps. If a payment landed in the gap between the read and the write — which is a matter of milliseconds, and therefore happens — the write-off proceeded anyway and papered over a payment that had just been received.

Nothing errored. The balance was zero either way. But the ledger recorded abandoned for money that had actually arrived.

The fix was to make the condition travel with the write, so the update itself refuses if the state has changed since it was read, rather than checking first and trusting the world to hold still.

The general form: any check followed by an action is a race unless the check is part of the action. In financial code this is not a theoretical concern. It is the mechanism behind double payments, double refunds and reversals of things that were never done.

Ageing is what prevents the ambush#

Write-offs are unpleasant partly because they arrive in clusters at year end, when somebody finally goes through open items.

The remedy is boring: age receivables and payables continuously, in bands, and put the old ones in front of somebody monthly. A balance that has been visibly ageing for six months is a decision waiting to be made. The same balance discovered in March is a surprise, and surprises get resolved under time pressure by whoever is in the room.

This connects to something structural. Old open items are very often not uncollectible at all — they are payments made in stages that the system never recognised as settled, or deliveries never matched to their order, or advances never recovered. Writing those off is not a commercial decision; it is destroying evidence of a data problem.

So the sequence matters: reconcile first, then age, then write off what is genuinely left. The reconciliation that settles most of them is against the other party's own ledger — when your ledger and theirs disagree. Writing off first is faster and it hides the thing that would have prevented the next twenty.

Reversal, and why it must exist#

Occasionally a written-off amount is recovered. A vendor pays after all; a disputed claim settles.

That must be recordable, and it must be recordable as a reversal of a specific write-off, not as fresh income from nowhere. Otherwise the write-off history overstates losses, the recovery understates their relationship, and the pattern that would tell you which write-offs were premature is invisible.

The requirement is the same one that applies to every correction in a financial record: entries are added, never edited, and the history stays readable. That principle has its own piece — append-only records.

The short version#

A write-off is a decision to stop pursuing a real balance.

Keep it distinct from a correction and from a settlement, put it at the same authority level as spending the same money, and never let the person measured on the balance be the one who erases it.

Make the reason a required, structured field, refuse to delete anything that carries those reasons, and reconcile before you age and age before you write off.

The number is the least valuable part of the record.

That is almost never where the time went. The time went in the gaps between people — the intervals when a task had been finished by one person and had not yet started with the next, because the next person did not know it was theirs.

The three kinds of stall#

Nobody knows it is theirs. The most common by a wide margin. The work moved on and the notification did not, or arrived somewhere nobody looks.

Everybody thinks it is somebody else's. A task with two names on it and no statement of who acts. Diffusion of responsibility is not a failure of character; it is what happens when a system permits ambiguity. The same thing at the scale of a project is one project, many contractors, where the delay sits in the handover between two trades rather than inside either.

Somebody knows it is theirs and is blocked. The only one of the three that is visible, and consequently the only one that gets managed.

Most attention goes to the third. Most of the delay is in the first two.

The stall nobody can report#

A document was sent for signature in our own system. It sat there. The person who had to sign it did not know they had to sign it.

They were not ignoring it, and they had not missed a message. The message had arrived exactly as the system intended, and the way the system intended was wrong. The request went out carrying a generic type — question — which had been mapped, sensibly enough, onto the row for comments in the notification grid. That row's default delivery is a digest: held back until the next scheduled broadcast, ringing nothing, arriving as one line among a dozen others that did not need doing right now.

A document holding up a payment was delivered as chatter. The full account is filed as chatter.

The important part is why nobody reported it. The person who had to sign did not know there was anything to report — from where they stood, nothing had happened. The person who sent it assumed it had landed, because sending it produced no error. Both held a completely consistent picture of the day, and the two pictures did not overlap at the point where the work was stuck.

That is the most durable kind of stall. It has no owner because nobody experiences it as a problem.

What a request has to say#

The useful question about any handover is not how important it is. Everybody's own work is important, and a priority scale where everything is at the top is not a scale.

The useful question is what it asks the reader to do, and there are only three answers:

• Nothing. You should know this happened. Read it whenever.
• Later. Look at this next time you are looking at things.
• Now. Somebody is standing still until you act.

A signature request is always the third. It is not information about work; it is a request for a specific person's hand, and until that hand moves a document, a payment and usually another human being are all stopped.

Classify by what is being asked rather than by how important it feels, and the routing follows without anybody having to argue about priority. The wider argument is in an alert that rings for everything.

Make the waiting visible from both ends#

A stall persists because it is invisible to the two people best placed to end it.

The person waiting often cannot see what they are waiting on — only that nothing has happened. The person holding it cannot see that anybody is waiting.

Two cheap fixes cover most of it.

A standing statement on the work itself, in plain words: what it is waiting for, who it is waiting on, and how long it has been waiting. Not a status code. A sentence. We added exactly this to every task in our own system after watching people ask the same three questions in meetings that a line of text could have answered.

A view of what is waiting on me, that is genuinely complete. Incomplete is worse than absent, because a list that misses things teaches people they still have to check everywhere else, and then they stop using the list.

The pause that nobody owns#

There is a specific structural stall worth naming: the interval where a task has left one stage and not yet entered the next.

Approved but not yet issued. Signed but not yet filed. Received but not yet booked. Ready but not yet started.

These intervals have no assignee by definition, and most systems represent them as a status rather than as somebody's work. So no queue contains them, no reminder covers them, and they can last indefinitely without appearing anywhere as late.

The fix is to make every state have an owner, including the transitional ones. If the answer to "whose is it right now" is "nobody's, it is between stages", the process has a hole and the hole will fill with time. Where the next actor is outside the company altogether, that owner belongs in a different system — a CRM and a task system are not the same thing.

Chasing is a finite resource#

The instinct once stalls are visible is to add reminders. It works briefly.

A reminder that is occasionally wrong teaches people to skim the whole class of reminder, and once they skim it, the one that matters costs the same as the ones that do not. We watched a chaser ring our finance team every few days about money that had already left the account, because of a stale field elsewhere in the system. Nobody reported it. They just stopped reading that kind of message, and the credibility spent was not spent only on that chaser — it was spent on every chaser in the building.

So: fewer, better-targeted, and correct. A chasing system's accuracy is not a nice-to-have. It is the whole asset.

The short version#

Work stalls in the gaps, not in the hands.

Classify requests by what they ask a person to do, give every state an owner including the transitional ones, put a plain sentence on the work saying what it is waiting for, and keep reminders rare enough and right enough to still be read.

And when something has been stuck for a month, look first at how the request was categorised on its way to the person who was supposed to act on it. The answer is usually a row in a routing table, not a failure of diligence.

Three months later something goes wrong that would not have gone wrong before, and the explanation is always the same shape: he knew how to handle that.

Why handover documents miss the important things#

Because the important things do not feel like knowledge to the person who has them.

Anybody doing a job for a few years has absorbed a large body of situational knowledge that they no longer experience as knowledge. Which supplier's delivery notes are always short by a bag. Which approval genuinely needs chasing and which arrives on its own. Which of two similarly named items in the system is the one actually used. That the report on Tuesday is wrong unless you run the other one first.

None of this appears in a handover document, because a handover document is written by asking somebody what they do, and people answer that question by describing their formal responsibilities.

This is the same mechanism that hides ordinary defects from the people living with them. A problem that survives longer than a month or two stops being experienced as a problem and gets absorbed into the description of the job. We wrote about that at length in the gap you stopped noticing. Handover surfaces the same blindness under time pressure.

The three categories, and only one of them transfers well#

Documented process. Transfers fine. It is written down, it can be read. This is what handover documents contain, and it is the least valuable third.

Undocumented routine. The daily and monthly things nobody wrote down because they are too obvious to mention. Partly transferable, if the overlap period is long enough for the successor to watch a full cycle. A month is not a full cycle for anything with a quarterly component.

Judgement and relationships. Which vendor will actually turn up on a Sunday. Which colleague to ask before formally raising something. What the unwritten tolerance is on a particular measurement. Barely transferable at all in a handover, and it is often the majority of what made the person good.

Knowing which of the three you are losing tells you what to do. The first needs nothing. The second needs a longer overlap covering a real cycle. The third needs relationships to be introduced deliberately, one at a time, rather than listed.

Ask about workarounds, not about duties#

The single most productive handover question is not "what do you do".

It is: what do you work around?

Ask it out loud and wait through the pause. The answers do not come as complaints. They come as instructions, delivered helpfully, in the tone of somebody explaining how a door has to be lifted before it will close. Oh, you have to enter it twice, the first one never saves. Don't use that report, use this one. Ring him rather than emailing, he doesn't check.

Every one of those is a piece of load-bearing knowledge that no document would have captured, because from the inside it is not knowledge — it is just how the job is done.

It is also, incidentally, a free audit of your own systems. Each workaround is a defect somebody has been quietly staffing. We found an entire class of these in our own software — features that had been built and had never been given a button, so a workaround was doing the job instead and nobody had ever filed a request. The story is written, and never wired.

The things that actually break#

In practice, handover failures cluster in a small number of places.

Access. Accounts, keys, permissions, and the one system nobody remembered because it is used twice a year. The successor discovers the gap at the moment they need it, which is the worst moment.

Recurring obligations with long periods. Anything annual. A renewal, a return, a certificate, an inspection. The predecessor did it eleven months ago and will not think of it; the successor has never seen it happen.

Relationships that were personal. A supplier who gave good service because of a person, not because of a contract. This degrades quietly over months and is usually attributed to the supplier.

In-flight decisions. Anything half-negotiated. The state of a discussion lives in somebody's head and in a set of messages nobody else can read, which is the same reason a snag list that actually closes gives every item an identifier and a named owner rather than a wording.

Undocumented commitments. Something promised verbally that the records do not show. These surface as accusations of bad faith.

What a handover should actually produce#

Not a document. A set of artefacts that outlive the meeting.

• A calendar with the annual and quarterly obligations on it, each with the name of whoever must be told and roughly what is involved. This is worth more than everything else combined.
• A list of access held, including the awkward ones — shared logins, a physical key, an account in somebody's personal name.
• A written list of in-flight items with their current state and who the other party is.
• Introductions made in person to the five or six relationships that matter, with the predecessor present and saying so.
• The workaround list, from the question above, in their own words.

Notice that four of the five are lists of specific facts rather than descriptions of a role. Roles do not transfer. Facts do.

The same test decides what goes into the document set handed over at the end of a project — what belongs in a handover file.

Overlap is not the same as availability#

"Ring me if you need anything" is offered sincerely and used twice.

The successor will not ring, for ordinary human reasons: they do not want to look incapable, they do not know what they do not know, and after a fortnight it feels like an imposition. Availability is not a handover mechanism, and planning around it is how organisations end up depending on the goodwill of somebody who no longer works there.

If knowledge has not moved during the overlap, it has not moved.

The short version#

Handovers fail on the knowledge the departing person does not know they have.

Ask what they work around rather than what they do. Cover a full cycle, not a convenient window. Produce lists of specific facts — obligations, access, in-flight items, relationships — rather than a description of the role.

And treat every workaround you uncover as a defect report, because that is exactly what it is. The related failure, where work stops in the gap between two people who both think it is with the other, is covered in why tasks stall between people.

The reason gate registers fail is almost never discipline. It is that they were designed by somebody sitting down, for somebody who is standing up.

What the gate is uniquely good for#

Three things nothing else on a site can do.

It sees everything. Stores see what reaches the store. Accounts see what is invoiced. The gate sees the vehicle, including the ones that turn round, the ones that go to the wrong site, and the ones nobody was expecting.

It fixes a time. A delivery has a moment, and that moment is often the only way to distinguish two similar loads from the same vendor on the same day.

It is the last point before commitment. After the barrier, material is on your site and getting it off again is a conversation. Before it, refusal is cheap.

What kills a gate register#

Too many fields. Every additional field reduces the completeness of all the others, because there is a fixed amount of time while a driver waits. A register with eighteen columns is filled in with four.

Fields that require lookups. Purchase order number, item code, vendor code. The person at the gate does not have these and cannot get them. Anything that requires leaving the barrier to look something up will be guessed or left blank.

Writing in conditions that do not permit writing. Rain, dark, one hand on a torch. A paper register in a shed twenty metres from the barrier is filled in afterwards from memory, which is the same as not having one.

No feedback. Nobody at the gate ever finds out whether what they wrote was useful. A record that disappears into a system that never answers back is a record whose quality decays, because there is nothing to maintain it against.

The fields that earn their place#

For an inbound vehicle: date and time, vehicle number, what it is carrying in ordinary words, who it is from, the delivery challan number if there is one, and who received it.

For an outbound vehicle: date and time, vehicle number, what is leaving, on whose authority, and where it is going.

The outbound half is the one that is usually thin, and it is the half with the security value. A gate that records arrivals meticulously and departures casually is watching the wrong direction.

Two of those fields do most of the work. Vehicle number is the handle that connects a gate entry to a store receipt to an invoice, and it is the one thing the person at the barrier can always read. Time separates otherwise identical loads.

Photograph rather than transcribe#

The single largest improvement available to most sites is to stop transcribing and start capturing.

A photograph of the challan, taken at the barrier, contains every field on it, takes two seconds, requires no lookups, works in the dark with a flash, and cannot be misheard. The transcription can happen later, by somebody at a desk, or by a machine — and if it happens badly, the original is still there.

We built our own capture around exactly this, because it was already happening: site staff were photographing delivery slips into WhatsApp without being asked to, because it is the fastest thing a person holding a phone can do. The software's job was to accept that rather than to ask for something else. There is a longer piece on that principle — WhatsApp is the interface, whether you designed for it or not.

Two warnings from doing it.

Machine-read text from a photograph is a suggestion, not a record. It gets digits wrong, and a challan number with a wrong digit is worse than no challan number because it looks usable. A person confirms.

And a photograph without the vehicle number and time attached is much less useful than it seems, because it cannot be placed. Capture those two as fields even when everything else is an image.

The expected-arrivals list, and how it goes wrong#

A good gate screen shows what is expected today. It lets the guard say yes, you are on the list or wait, you are not.

Ours was built to do that, and it had a defect worth describing because it is the sort that hides for a long time.

The list refused any load whose money had not settled, which is sensible. But an order paid in stages never wrote the field that meant this is paid — when a payment has a schedule, the stages are the payment record. So a load that had been paid for to the last rupee never reached the list, and a fully-paid lorry arrived at the barrier unannounced.

That is the exact event the screen exists to prevent. It had been prevented in every case except the ones paid in the way the biggest orders are paid. The full account is a fact that had no owner.

The general warning: an expected-arrivals list is only as good as its completeness, and a list that silently omits a category trains the guard to treat absence as meaningless. Then the list stops doing anything at all. What the barrier needs to be told before a vehicle arrives, and what happens when it has nothing, is why a lorry surprises the gate.

Design for the person, not the record#

Two details that sound trivial and decide whether the whole thing works.

Very large tabular numerals. A vehicle number read at arm's length in sunlight, entered on a phone by somebody wearing gloves.

Language and pictograms rather than prose. Gate staff on Indian sites may read neither English nor the language the rest of the application is in. A screen built on symbols, big numbers and the local script works for everybody; a screen built on English labels works for the people who designed it.

We kept our gate screens deliberately untouched during a site-wide typography change for exactly this reason — they had never leaned on English typographic convention in the first place, so they had nothing to lose. That story is in capitals are a contrast, not a volume.

The short version#

The gate sees everything, once, and only briefly.

Cut the fields to what can be captured in the time a driver will wait. Prefer a photograph to a transcription. Make vehicle number and time non-negotiable. Watch the outbound direction as carefully as the inbound one.

And make sure whatever list the guard is checking against is actually complete, because an incomplete list is quickly treated as no list.

The official system has forms, fields, validation and a login. The group has photographs, voice notes, half sentences and a great deal of information that never reaches the official system at all.

Most software projects in this space begin by trying to move people from the second to the first. It is a reasonable-sounding plan and it does not work.

Why the group wins#

Not because people are resistant to change. Because on the measures that matter to somebody standing in the sun, the group is genuinely better.

It is already open. No login, no app switch, no waiting for a page.

It works on a bad connection, and it queues and retries without being asked.

It accepts a photograph as a complete message. A picture of a delivery slip contains everything the form was going to ask for, and takes two seconds.

It accepts speech. A site engineer sends a voice note because his hands are dusty and the screen is in the sun.

Everybody is already in it, including the people who will never be given a licence for your software — drivers, contractors' supervisors, the fabricator.

It is forgiving. No field is mandatory. Nothing is rejected for being incomplete.

A form on a phone competing with that loses on every axis. The competition is not close, and no amount of training changes an outcome that is determined by physics and attention.

The move that works#

Stop competing. Read the group.

Treat the messages as the input and do the structuring afterwards, on your side, where somebody has a keyboard and a moment. The person on site changes nothing about what they do.

This is not a lowering of standards. The structured record still gets created, still gets validated, still gets confirmed by a person. What changes is who does the structuring and when, and moving that work off the site and into the office is almost always correct, because the site is the place with the least available attention on the whole project.

What we got wrong first#

Our software recognised a photograph as a delivery record only if its caption contained one of four words: challan, bilty, GRN, delivery.

Measured against four hundred real captions that the site team had actually sent, those four words matched exactly two.

What people really write is the material and a quantity — a grade and a volume and a weight. Or the vehicle and the fact that it has arrived. Or a plain list: a trader's name and then two numbered lines with quantities and units.

Reading those three shapes instead — the material named directly, the vehicle that brought it, or any quantity with a unit — took the match rate from two to thirty-four out of the same four hundred captions.

The vocabulary was never the site's problem. It was ours. A longer piece on that is the words the site already uses.

Fifteen hundred photographs had been sent from site before this was fixed, and not one had ever become a delivery record. That is why no quantity appeared anywhere. Nothing had failed loudly. The photographs kept arriving and kept producing nothing.

Voice notes are the same problem again#

Once the pictures were being read, the voice notes were still a labelled blob that nobody opened.

The comment in our own code had known why for over a year — a site engineer sends a voice note because his hands are dusty and the screen is in the sun — and we had done nothing about it.

Transcribing them was the obvious half. The half that mattered was what happens to the words afterwards: a spoken incident report classifies and registers, a spoken answer to an evening question is treated as that answer, a spoken question gets an answer grounded in the records. Same doors, same functions as a typed message takes. Not a parallel path, by construction — because a parallel path is a second implementation of every rule, and second implementations drift.

That piece has its own account: the voice note is the report.

The rules that keep it honest#

Reading a group chat as an input has real risks, and three rules cover most of them.

Everything the machine concludes is a suggestion. A photograph that looks like a delivery slip becomes a proposed record, matched to a proposed order, which a person confirms with one tap. Never an automatic entry. The reasoning is in the machine proposes, a person decides.

Refuse the obvious non-cases loudly rather than guessing. A cylinder going out for refilling, a photograph of a damaged divider, a weight dispute — these look superficially like delivery messages and are not. A system that files them as receipts is worse than one that files nothing, because somebody now has to find and remove them.

Privacy is a boundary, not a filter. This one we got wrong and had to fix. Our text extraction ran before the check that knew which rooms were private, so a personal photograph was being read and, if its text resembled a delivery slip, filed as a goods receipt. The correction was not to discard the result afterwards — it was to exclude private rooms at the query, so the bytes are never fetched at all. A privacy control that operates after processing is not a privacy control.

What you still need the real system for#

Reading the chat does not remove the need for a system of record. It changes what the system of record is for.

The chat is where events are reported. The system is where they are confirmed, structured, connected to money and orders, and kept. Signature, authority, audit trail and reconciliation all belong on the system side, and none of them can live in a group chat, for reasons set out in what an audit trail is for.

The division that works: the site reports in the medium it already uses; the office confirms in the system that keeps records. Nobody is asked to change their behaviour to suit software.

The direction back out carries a decision of its own — whether a message leaves from the company or from the colleague the other side already knows: one WhatsApp number, or one per person.

The short version#

The group chat is not a workaround people will grow out of. It is the interface, because it wins on every dimension that matters to somebody on a site.

Read it. Read it in the vocabulary people actually use, not the vocabulary your forms were written in. Treat everything the machine concludes as a proposal. And keep the record-keeping where records belong.

So any attendance system that requires a live network will fail, and it will fail in a specific pattern: it works at the office, it works during the demo, and it produces gaps on the days people were furthest from a tower.

The engineering answer — queue the punches on the device and send them when the network returns — is straightforward. What is not straightforward is keeping the data honest once you have accepted records that were created while nobody was watching.

What offline actually means for a record#

A punch created offline carries three claims: a person, a place, and a time. All three were asserted by a device that was not in contact with anything at the moment of assertion.

That is a genuinely different kind of record from one created against a server, and it needs different rules.

Identity. The punch must authenticate as the device's own credential, never as an identity supplied in the message. If the payload says who it is from, then anybody who can reach the endpoint can be anybody. Our devices carry their own token, issued once, stored only as a hash, and the punch authenticates as that device rather than as whatever the message claims.

Time. The device clock is under the user's control. A punch that arrives claiming a time from six hours ago may be a genuine queued punch or a device whose clock was changed. Record both the claimed time and the received time, always, and let a person see the difference where it is large. Silently trusting one or the other is the wrong answer in both directions.

Place. A punch with no position fix should be refused rather than filed at a default location. We enforce this explicitly: no fix, no punch. The alternative is an attendance record that says somebody was at the point where the equator meets the prime meridian, which is worse than a missing record because it will not look missing.

The duplicate that arrives twice#

A flaky network is not a network that fails. It is a network that succeeds after the client has given up.

So the same punch will be delivered twice, or five times, and the system must fold those into one. This requires the punch to carry an identifier generated on the device at the moment of creation, so that two arrivals of the same event are recognisable as the same event rather than as two events with similar details.

Deduplicating on person plus time is the obvious approach and it is wrong in both directions: it merges two genuinely separate events that happened in the same minute, and it fails to merge one event whose claimed time was recomputed between retries.

Permanent refusal and temporary refusal#

This is the rule that saves a support burden, and almost nobody builds it in first.

When the server refuses a punch, the phone needs to know which kind of refusal it was:

• Try again later. Server busy, transient failure. Keep it queued.
• Stop retrying this one. Malformed, duplicate of a settled record, outside any permissible window, from a revoked device.

Without that distinction a permanently invalid punch retries for ever, draining a battery and filling logs. We marked our four payload refusals explicitly as permanent for exactly this reason.

Location is not attendance#

A phone that reports its position in the background is a genuinely useful thing, and it is the fastest way to build something nobody trusts.

The line we drew, and would draw again: background location is a signal, not an activity.

Concretely, that means a background position sample never counts toward the presence window, never counts as an activity, never decides which site somebody was at for the day, and never on its own grants access to anything. It is recorded, and it is recorded only while the person is punched in — with the server enforcing that, not the app.

The reason is not squeamishness. It is that an attendance figure derived partly from deliberate punches and partly from ambient location is a figure nobody can explain. When somebody disputes a day, you need to be able to say what was recorded and by whom. Mixing an act with an observation destroys that distinction permanently — and the dispute is rarely academic, because these are the numbers a labour contractor's bill is built from, as paying a labour contractor sets out.

Two further details that turned out to matter. A device battery level and the kind of position fix are worth storing alongside the sample, because they explain a lot of otherwise inexplicable gaps. And a step count from a phone should be nullable, never zero-by-default — no phone reported and the person did not move are different facts and collapsing them loses the ability to tell a dead battery from a stationary day.

One law, two doors#

The strongest structural rule we applied: an offline punch from the phone goes through the same function as a punch from the web.

Not a similar function. The same one, with a different authentication route into it. Every rule about permissible windows, about sites, about duplicates, about what a punch may and may not do, lives in one place and applies to both.

The temptation to write a separate, simpler path for the device is strong, because the device's needs are different and the shared function has awkward edges. It is the same temptation that produces two implementations of any rule, and the result is always the same: they agree at first and drift, and the drift is silent because each is internally consistent. That is the failure described in a fact that had no owner, arriving from a different direction.

The kill switch has to cover both doors#

One more thing, learned by asking the right question at the right moment.

If there is an emergency lock that stops the application, it must stop the device door too. A panic lock that stopped every screen but let phones keep posting locations would not have stopped anything — it would have produced a system that looked locked and was still collecting.

Any capability reachable by a second route needs every control that applies to the first, and it is worth walking every door in a system and asking that question explicitly rather than assuming.

The short version#

Offline attendance is not a networking problem. It is a trust problem.

Authenticate the device rather than the message. Record claimed time and received time separately. Refuse a punch with no position rather than inventing one. Distinguish permanent refusals from temporary ones. Keep background location as a signal that never becomes an activity.

And send both routes through the same law, because two implementations of one rule is two answers waiting to happen.

The related question of how site staff report anything at all when the network is poor is covered in WhatsApp is the interface.

It is filed. It is very rarely read. And when a dispute arises two years later it becomes the most important document on the project, at which point everybody discovers what was actually in it.

The three purposes, which conflict#

A DPR is asked to do three jobs, and they pull in different directions.

Management information. What happened today, so somebody can decide what to do tomorrow. Wants to be short, current and comparative.

A contemporaneous record. Evidence of what occurred, for claims, disputes, insurance and delay analysis. Wants to be complete, specific and dated, and its value increases with detail.

Compliance. A form somebody requires. Wants to be filled in.

Design for the first and it is useless in a dispute. Design for the second and nobody will complete it daily for two years. Design for the third and you get a form that satisfies nobody and is completed by copying yesterday's.

Most DPRs are the third, because the third is what survives when the other two have no advocate.

Why the third one wins#

The person writing it gets nothing from writing it.

That is the whole mechanism. The site engineer already knows what happened today. The report costs them twenty minutes at the end of a long day and returns them nothing at all. No decision comes back, no question is answered, nobody comments on it. The only feedback they ever receive is when it is missing.

Under those conditions a rational person minimises effort, and the report becomes a slightly modified copy of the previous one. This is not dishonesty. It is what any incentive structure of that shape produces, and it will not be fixed by insisting harder.

The two things that change the outcome#

Make it shorter than it is worth arguing about. Most DPR forms ask for things that could be derived from other records — material received, attendance, plant hours, weather. If those exist elsewhere in the system, they should be pulled in, not typed again. Re-typing what a machine already knew is the most reliable way to teach somebody a form is not serious.

Give something back. A report that produces an answer, a decision, or a visible acknowledgement is a report people complete. One that disappears is not. This is the single highest-leverage change available and it costs nothing technical — somebody senior reading it and replying two sentences, most days, is enough.

The fields that matter in a dispute#

If the second purpose is real — and on any project of size it is — a small number of fields carry almost all the evidential value, and they are not the ones forms usually emphasise.

• What was actually done, located. Not "continued blockwork" but which area, which level, which grid. Unlocated work cannot be tied to a delay later.
• Who was on site, by trade and number, and whose people they were.
• What stopped, and why, and for how long. The single most valuable line in any progress record. Waiting for a drawing, waiting for material, waiting for an inspection, rain. Delay claims are built entirely from these and they are the first thing omitted when somebody is in a hurry.
• Instructions received, and from whom. Verbal instructions become disputes about whether they were given.
• Weather, recorded honestly rather than as a category.
• Plant on site and whether it was working.

Notice that three of those six are about things not happening. A progress report that can only record progress cannot record the reason there was none, which is exactly the information anybody will want. The wider question of what belongs in writing and what should stay out of it is what a site engineer should record.

Photographs are the report, if you let them#

The most complete daily record on most sites is already being produced and is not being kept: the photographs people take.

They are taken constantly, they are located, they are timestamped, and they show what a paragraph cannot. The reason they are not the record is that they are unlabelled, live in a chat, and nothing indexes them.

That is a solvable problem and a much smaller one than getting people to write more. Our own experience is that the photographs were already arriving in volume — over a thousand of them — and had never become anything, because the system was looking for a typed caption and site photographs usually have no caption. The picture already says everything, so nobody types.

The general principle is in a site photograph is a record, if anything reads it.

Ask, do not require#

There is a version of daily reporting that works far better than a form, and it is a question.

Once a day, to the people with unfinished work, in the medium they already use, a short list of what is outstanding — with a small number of honest answers available. Done. Moved to tomorrow. Moved to a date. Stuck, and here is why.

Four answers, each running the same action the application itself would run. It takes ten seconds rather than twenty minutes, it produces structured data rather than prose, and the "stuck, and here is why" answer collects the single most valuable field in progress reporting without anybody having to think of it as reporting.

We built ours as an evening list on WhatsApp, capped at a handful of items, respecting leave. The cap matters: a list of thirty things is not a question, it is an accusation, and people stop answering.

Do not use it as a performance record#

The fastest way to destroy the honesty of a daily report is to use it to judge the person writing it.

The moment "waiting for material, four hours" becomes evidence in somebody's appraisal, that line stops appearing. What replaces it is a report full of activity and empty of obstruction, which is precisely the report with no evidential value. The same pressure inflates the percentage at the top of a weekly report — reported progress and real progress.

If you want to know where time actually goes, the reporting has to be safe. The same logic applies to escalation, which is why we built ours to surface slipping work without anybody having to name a colleague — escalation without shame.

The short version#

A DPR fails because writing it returns nothing to the person writing it.

Shorten it to what only they know, derive the rest, reply to it so it is visibly read, and capture the photographs that are already being taken.

And make sure it can record the absence of progress, because that is the part somebody will need.

They are also, on most projects, worth nothing at all, because nothing reads them.

Why the photograph exists in the first place#

Somebody takes a picture instead of writing because the picture is faster and more complete. A delivery slip photographed contains every field a form would have asked for. A crack photographed says more than three sentences would, and photographed again after the repair it is what closes the item on a snag list that actually closes.

That behaviour is not laziness to be corrected. It is a correct assessment of effort against information, made by somebody who is standing up and busy. The question for a system is not how to stop it. It is how to accept it.

The gap between capture and record#

We had over a thousand photographs sent from site whose text had been machine read and stored, and nothing had ever looked at the result.

The check that should have used it read only the caption somebody typed. And site photographs usually have no caption, because the delivery slip in the picture already says everything, so nobody types.

The extraction worked. The storage worked. Nothing was broken and nothing had errored. The output simply had no consumer, and a produced result with no consumer looks — from every direction, including from the inside — exactly like a feature that was never built.

This turns out to be one of the commonest classes of defect we find. Work that was done, correctly, and never wired to anything. The general case is written, and never wired.

What a photograph needs to become a record#

Four things, and only the first is about the image.

A subject the machine can identify. A delivery slip, a hazard, a defect, progress, a person, a meter reading. Roughly, is this a document, a condition, or a scene.

A place. Which site, which area. Usually derivable from who sent it and when, which is much more reliable than asking.

A time. Almost always present and almost always trusted too readily — a photograph of a photograph, or a picture taken yesterday and sent today, both carry misleading times.

A connection to something. An order, a task, a location, a person. A photograph attached to nothing is not a record; it is an image in a folder.

The fourth is where nearly all the value sits and where nearly all systems stop.

Reading the text is the easy half#

Extracting text from a photograph of a document is a solved problem to a useful degree of accuracy. Getting from that text to the right record is not.

Our extraction was reading delivery slips correctly and matching them against nothing, because the matcher only considered purchases that had not yet been paid — and in our process, payment precedes dispatch. By the time material arrived and somebody photographed the slip, the correct purchase was always paid and therefore never a candidate. Every slip matched nothing. A slip matched to nothing appears on no screen at all.

The reading was never the bottleneck. The connection was.

Three rules we ended up with#

Machine reading produces a suggestion. Extracted text gets digits wrong, and a document number with a wrong digit is worse than a missing one because it looks usable. Every match is a proposal a person confirms with one tap, and a rejection is remembered so the same wrong pair is never offered again. The argument is in the machine proposes, a person decides.

Refuse the obvious non-cases rather than guessing. A cylinder going out for refilling, a vehicle that damaged a divider, a weight dispute — these look superficially like delivery messages. A system that files them as receipts is worse than one that files nothing, because somebody must now find and remove them.

Privacy is enforced before processing, not after. This one we got wrong. Our text extraction ran before the check that knew which rooms were private, so a personal photograph was being read and, if the text resembled a delivery slip, filed as a goods receipt. The correction was not to discard the result afterwards. It was to exclude private rooms at the query, so the bytes are never fetched at all.

A privacy control that runs after the data has been processed is not a privacy control. It is a cleanup.

Not every photograph should be quiet, and not every one should ring#

There is a routing decision hidden in this that took us a while to see.

A contractor's room is correctly kept at arm's length — their progress photographs are their business and notifying our staff about each one would be noise. But a photograph that reads as a hazard or a defect is exactly what the channel was added for, and keeping that quiet is a different kind of mistake.

So the rule is by content, not by source: hazard photographs notify, progress photographs do not, regardless of which room they came from.

The general shape of that decision — classify by what the message asks somebody to do, rather than by where it came from or how important it feels — is the subject of an alert that rings for everything.

What to do with the archive you already have#

Most organisations have years of photographs sitting in chat history, in folders named by date, on individual phones.

That archive is worth something, but not much, and it is worth being honest about why: it has no connections. Reprocessing it will give you dated, located images and very few links to orders, tasks or events, because the records those would connect to have moved on.

The better investment is almost always forwards. Get the pipeline right from today — subject, place, time, connection, with a person confirming — and let the archive be what it is, which is a searchable pile that occasionally settles an argument.

The short version#

Site photographs are already the richest record you have and almost none of them are records, because nothing consumes them.

Reading the image is the easy part. Connecting it to an order, a task or a location is the hard part and the valuable one.

Suggest rather than file. Refuse the obvious non-cases. Enforce privacy before the bytes are fetched. Route by what the picture shows, not by where it came from.

And check, in your own tools, whether anything is actually reading the output of the thing you built to produce it. The answer is surprisingly often no.

The reason is rarely written down: escalating means naming somebody. To report that a task is stuck, you have to say who it is stuck with. To report that material has not arrived, you name the person who was buying it. And the person you are naming will be at lunch with you tomorrow.

So people wait. They wait until the problem is large enough that raising it is clearly justified, which is usually after the point at which it could have been fixed cheaply.

What the delay costs#

Not the escalation itself. The window.

Almost everything on a construction project is fixable if you know about it a week early and expensive if you know about it a week late. A material that has not been ordered can be ordered. A drawing that has not arrived can be chased. An approval that has not moved can be pushed. The same three problems, found after the crew is standing idle, cost their delay plus everything downstream.

An escalation system that reliably fires two weeks late has not reduced the number of problems. It has removed the only period in which they were cheap.

Design so nobody has to accuse anybody#

The move that changes behaviour is to make the system, rather than a person, be the one that notices.

Concretely, that means surfacing conditions rather than reports:

• Work that has slipped its date more than once.
• A task waiting on the same thing for longer than similar tasks usually wait.
• An approval sitting unactioned past the point where approvals normally move.
• A payment stage past its date.
• A delivery expected and not arrived.

Each of those is computable from data the system already holds. None requires anybody to file a complaint. And because the observation is mechanical, the conversation it produces starts from a fact rather than from an allegation — this has moved twice is a much easier sentence to open with than he keeps missing it.

We built ours this way deliberately: chronically sliding work surfaces itself, so nobody has to snitch. The word is the right one, because that is exactly what people feel they are being asked to do. It matters most at the boundary between two agencies, where the problem belongs to neither of them — one project, many contractors.

Predict rather than report#

The next step is to notice before the date rather than after it.

A late task is a fact. A task likely to be late is a warning, and it is the warning that has value, because it arrives while there is still time.

The inputs are unremarkable: how long this kind of work usually takes, how much of the remaining time is left, whether it has been pushed before, whether the person holding it is carrying an unusual load, whether it is waiting on somebody who is on leave. None of this is clever. Most organisations have all of it and use none of it, because nobody has ever been asked to compute a forecast for a task.

Two rules make it usable rather than annoying.

It goes to the person who can act, not to everybody. A slip-risk warning broadcast widely is a public prediction of somebody's failure, which is exactly the shame problem again, arriving from the other direction.

It says why it thinks so. A score with no explanation is either believed blindly or ignored entirely, and both are useless. Pushed twice, two days left, usually takes five is actionable. A number out of a hundred is not. The general form of that requirement is the app should tell you why.

The scoring mistake we made#

Our early risk scoring treated every task settled stage-by-stage as money not yet paid, because a staged payment never wrote the field meaning paid. That added a substantial pile of pure noise to a board built to show what actually needs a human.

A warning system that cries wolf gets ignored, and it gets ignored wholesale — people do not learn to discount one category of false positive while remaining alert to the rest. They discount the board.

The underlying fault was the same one that had leaked into eight other places in the application, and it is described in a fact that had no owner. Its relevance here is narrower and worth stating plainly: the accuracy of an early-warning system is not a quality attribute, it is the entire asset. A risk board that is right most of the time is not most of a risk board. It is nothing.

Ask the person first#

Before anything goes upward, the person holding the work should have had a chance to say what is happening, in a form that takes seconds.

A short evening list of what is outstanding, with a small number of honest answers — done, moving to tomorrow, moving to a date, stuck and here is why — resolves most of what would otherwise have escalated, and it does so without anybody being told on.

The fourth answer is the valuable one. Stuck, waiting for the drawing is a complete escalation, filed by the person best placed to file it, without requiring them to make a complaint about anybody. It arrives as an explanation of their own situation rather than as a report about somebody else's.

Cap the list. A list of thirty items is not a question, it is an accusation, and people stop answering. Respect leave, or the first message somebody gets on returning from a funeral will be a demand.

What escalation should look like when it does happen#

• Addressed to somebody specific, who can act.
• Stating the condition, not a judgement. What has happened, how long, what it is waiting on.
• Carrying its own history. How many times, since when, what was tried.
• Closable. An escalation with no way to say resolved, because this stays open and pollutes the next one.

And it should be quiet by default. An escalation that arrives with alarm attached spends attention that a later, more serious one will need. Attention is a fixed supply, which is the subject of an alert that rings for everything.

The short version#

People do not escalate because escalating means naming a colleague.

Let the system notice instead. Compute the conditions rather than requiring reports, warn before the date rather than after it, tell the person who can act and tell them why, and give the person holding the work a two-second way to say they are stuck.

And make sure the warnings are right. An early-warning board that is frequently wrong is not a partly working control. It is an ignored screen. The related question of where the time actually goes is in why tasks stall between people.

The thing that made it late happened much earlier — a date quietly moved, a dependency that never arrived, a person who took on three things in a week when they normally take two. All of those were visible at the time. None of them were counted, because organisations track completion and lateness, and slippage is neither.

Lateness is a lagging indicator#

By definition, a task is late after the point at which anything could have been done about it cheaply.

Everything useful happens in the period before. That period is where a conversation costs five minutes, where material can still be ordered, where an approval can still be chased in time. Once the date has passed, the same problem costs the delay plus the disruption to everything sequenced behind it.

So a board showing what is late is a report on decisions already made. Useful for accountability, useless for prevention.

The signals that precede a slip#

None of these is subtle. All of them are present in ordinary task data.

The date has moved before. Overwhelmingly the strongest signal. A task pushed once is a task with a reason; a task pushed twice is a task with a problem. Very few systems count pushes at all, because the field just gets overwritten.

The remaining time is small relative to how long this kind of work usually takes. Requires knowing the second number, which requires having kept histories.

It has not moved at all since it was created. A task with no activity is not necessarily stuck, but a task with no activity and an approaching date nearly always is.

It is waiting on somebody who is unavailable. Leave, travel, or simply carrying an unusual number of open items. This one is computable from the same system that holds the leave calendar and is almost never joined up.

Its dependency has slipped. Obvious, and requires that dependencies are recorded, which on most projects they are not except in a programme file that nobody updates.

Nobody has asked about it. Work that people are talking about tends to move. Silence around an item with a near date is a real signal.

Counting pushes properly#

If you do one thing from this piece, count how many times a due date has been changed and by whom.

It is one extra row per change and it converts an invisible pattern into a visible one. It also changes behaviour on its own, mildly and usefully: a date that is known to be counted is moved more thoughtfully.

Two cautions.

Distinguish a push from a reschedule. A date changed because the whole programme moved is not the same as a date changed because this task did not get done, and lumping them makes the count meaningless.

Do not make the count punitive. The moment pushing a date becomes a black mark, people stop pushing dates and start letting them pass silently, which is strictly worse — you lose the signal and gain nothing. The same dynamic that governs escalation without shame applies here exactly.

Say why, or the warning is noise#

A predicted slip has to arrive with its reasoning attached.

This is at risk is a number somebody either believes or dismisses, and after the second wrong one they dismiss all of them. Pushed twice, two days left, similar work usually takes five, waiting on an approval that has been open a week is a sentence somebody can act on, argue with, or dismiss for a good reason.

The requirement generalises well beyond risk scoring, and it has its own piece: the app should tell you why.

Accuracy is the whole asset#

Our first version of slip scoring counted every order settled stage-by-stage as money not yet paid, because a staged payment never wrote the field meaning paid. That put a large amount of pure noise onto a board whose entire purpose was to show what needed a human.

The board did not become partly useful. It became ignored — and it was ignored wholesale, because people do not learn to discount one category of false positive while staying alert to everything else on the same screen.

A warning system's precision is not a quality attribute to be improved over time. It is the thing itself. A board that is right most of the time is worth approximately nothing, because the cost of checking a wrong warning is the same as the cost of checking a right one, and after a few weeks nobody checks.

The stuck strip#

The other half of prediction is description, and it is much simpler.

Every task in our system now carries a plain statement of why it is stuck: what it is waiting for, who it is waiting on, and how long it has been waiting. Not a status code — a sentence.

This does more work than it sounds like. Most of the questions asked in project meetings are that question, asked out loud, one item at a time. Answering it on the item itself removes the meeting's main activity and, more importantly, makes the answer available to the person who could have unblocked it, who was not in the meeting.

It also makes the absence of an answer conspicuous. A task that cannot say what it is waiting for is usually a task nobody has looked at, and that is worth knowing on its own.

What to build first#

In order of value for effort:

1. Count date changes. One field, enormous signal.
2. Put a plain "waiting on what, since when" line on every item.
3. Join to the leave calendar, so work assigned to somebody who is away is visible as such.
4. Keep durations, so "how long does this kind of thing usually take" is answerable at all.
5. Only then, score. A score built on the first four is defensible. A score built on nothing is a random number with a colour.

Most organisations attempt the fifth first, because it is the one that looks like a product. It is the one that requires the other four.

The short version#

By the time something is late, the decision that made it late is weeks old.

The signals that precede a slip are ordinary and mostly uncounted — pushed dates above all. Count them, say why when you warn, warn only the person who can act, and never let the warnings be wrong often enough to be dismissed.

And put one honest sentence on every piece of work saying what it is waiting for. It answers, in advance, the question every status meeting exists to ask.

The reason is not preference. A person outdoors, holding a phone, with dust on their hands and sun on the screen, can hold a button and talk in five seconds. Typing the same content takes a minute and a half and requires reading what they have written, which in that light is genuinely hard.

So voice notes arrive constantly. And in almost every organisation they are stored as an audio file with a label, sitting in a thread, opened by nobody.

The comment that had known for a year#

The most uncomfortable part of our own version of this story is that we had written the reason down and then done nothing with it.

A comment in our code said, plainly, that a site engineer sends a voice note because his hands are dusty and the screen is in the sun. It had been there for a long time. The voice notes went on being a labelled blob nobody read.

That gap — between understanding a thing and having built for it — is a specific and common failure. It is not ignorance. It is that the understanding lived in a comment, which agrees with itself for ever and stops nothing. The same observation, made about a styling rule, is in capitals are a contrast, not a volume: a rule written as prose survives exactly as long as the memory of the argument that produced it.

Transcription is the easy half#

Turning recorded speech into text is a solved problem to a workable standard, including for Hindi and for the mixture of Hindi and English that people actually speak.

Doing it is not the interesting part. What happens to the words afterwards is.

The wrong answer — and it is the answer most implementations reach — is to put the transcript in the thread and stop. Now there is text nobody reads instead of audio nobody plays. The reporting problem is untouched.

Same words, same doors#

The rule we settled on is that a transcribed voice note takes the normal door.

A spoken incident report classifies and registers exactly as a typed one would. A spoken answer to the evening list of outstanding work is treated as that answer. A spoken question gets an answer grounded in the records, the same answer a typed question would get. A spoken report from a contractor becomes the same kind of card a written one becomes.

Not a similar path. The same two dispatch functions a typed message goes through, called with the transcribed text.

This is a construction constraint rather than a preference. A parallel path for spoken input would be a second implementation of every classification rule, every permission check and every routing decision in the system. Two implementations of one rule agree at first and then drift, and the drift is silent because each is internally consistent. That failure mode is described in a fact that had no owner.

What to do with audio that cannot be read#

Some recordings are unusable. Wind, machinery, a pocket recording, thirty seconds of a conversation with no subject.

The correct outcome is not to retry for ever and not to fail silently. It is to mark the item as tried and empty and leave the queue. That state is different from not yet processed and different from failed, try again, and collapsing the three produces either an endless retry loop or a queue that looks clean while quietly discarding things.

This is the same distinction that matters for offline attendance punches, where a phone must know the difference between try again later and stop retrying this one. It is in attendance on a site with no signal.

Where the transcription should run#

We run ours on our own hardware, with the same model the rest of the estate uses, and voice is treated as first in the queue because a person is waiting for the result.

Two reasons for keeping it local, and only one of them is about cost.

The first is privacy. A voice note from a site contains names, rates, complaints about people, and occasionally something personal that was sent to the wrong thread. Sending all of that to an external service is a decision somebody should make deliberately rather than by default.

The second is that it removes a dependency on a third party for a function people come to rely on daily. A transcription service that is unavailable makes the whole reporting channel feel broken, and site staff who try something twice and get nothing do not try a third time.

The privacy boundary comes first#

One rule we had to learn by getting it wrong on the image side, and it applies identically here.

Processing must happen after the check that decides what may be processed, not before. Our text extraction on photographs once ran ahead of the gate that knew which rooms were private, so a personal picture was read and, if its content resembled a delivery document, filed as a goods receipt.

The fix was not to discard the output. It was to exclude private material at the query, so the bytes are never fetched at all. A control that runs after processing is a cleanup, not a control.

For voice this matters more, because speech in a private thread is more likely to be personal than a photograph in one, and a transcript is far easier to read by accident than an audio file is to listen to.

What it changes on site#

Nothing, which is the point.

The person on site does what they were already doing. The report they were already making becomes a record. Nobody is asked to learn a form, to log in, or to change a habit that exists because of dust and sunlight. What that record has to carry, and what should stay out of it, is what a site engineer should record.

That is the general principle behind all of this work and it is worth stating plainly: when the field has settled on a behaviour, the software's job is to read that behaviour, not to replace it. The wider argument is in WhatsApp is the interface, whether you designed for it or not.

The short version#

Voice notes are how sites report, for reasons of dust and sunlight rather than preference.

Transcribing them is the easy half. Making the words take exactly the same path a typed message takes is the half that matters, because a parallel path is a second copy of every rule you have.

Mark unreadable audio as tried and empty rather than retrying for ever, run the transcription where the privacy decision is yours to make, and check that the privacy gate runs before the processing rather than after it.

That vagueness is not a documentation problem. It is a design problem, and it surfaces as software behaviour that nobody intended.

Seeing is not deciding#

The commonest structural mistake is to treat visibility and authority as one scale, so that anybody senior enough to see something is by construction allowed to change it.

They are different axes. A site engineer may need to see every payment on their project and should not be able to authorise one. An accountant may need to adjust stock valuations without being able to see who is on leave. A super administrator may see everything and still should not be able to move money alone, for reasons in why one person should never move the company's money.

Collapsing the two produces a system where the only way to give somebody information is to give them power, and the practical result is that people are either over-privileged or blind.

The permission checks that are actually wrong#

Three specific faults we found in our own system, each of which is common enough to be worth checking for in yours.

A check that asks the wrong question. The function that reversed a stock entry asked only whether the caller was an administrator — and, separately, allowed anybody whose name appeared on a row to cancel that row. Neither is the rule anybody would have written down if asked. Both were the rule for as long as nobody asked.

A check that reads the wrong field. We introduced a category of account that must be refused certain things, and implemented the test as a comparison against the account's primary role. That comparison misses any account carrying a second role, because the role field holds only the primary hat. The correct implementation was a property of the account in its own right, not a value of a field that happens to usually contain it.

That is a general trap. Any check written as role equals X is fragile the moment a person can hold two roles, and people always end up holding two roles.

A check that leaks through a second door. Our stock reversal could reach through the store's interface and cancel an entry that the gate had written — leaving the gate's own register saying the lorry arrived and the entry impossible to restore. The permission on the store door was correct. There was a second door.

The lesson from the third is procedural rather than technical: enumerate the doors. Every way into a piece of data, including the ones added later for a different purpose, and check each one against the same rule. A capability reachable by two routes needs every control that applies to the first route.

Errors that answer questions#

A subtle one, worth its own paragraph because it is easy to build by accident.

If a system responds differently to that record does not exist and that record exists but is not yours, then anybody can determine which records exist by guessing at identifiers and reading the difference in the responses. We had exactly this: a card could be filed onto any task in the company, signed with the filer's name, on a task they could not see — and its two different errors answered does task X exist? for anything anybody cared to guess.

The same refusal, either way. It feels unhelpful and it is the correct behaviour.

Grant, do not assume#

The most useful change we made in this area was to stop treating capabilities as implied by seniority and start treating them as granted keys.

Exporting data and importing data are the clearest examples. Both are powerful — an export takes information out of the building and an import writes over things — and both had historically been available to whoever happened to be senior enough to find the screen.

They are now explicit grants: held implicitly by the few people at the top, and given to anybody else person by person, on a panel where you can see the whole list and take one back.

Two properties make that work. The list must be visible in one place, so somebody can look at it and be surprised. And a grant must be revocable in one action, because a permission you cannot easily withdraw is one people are reluctant to give, and reluctance produces workarounds.

Delegation is a permission with a clock#

People travel. Work must continue. So authority gets handed over, and the handover is where most permission designs quietly fail.

The version that holds:

• Bounded in time, with an end date.
• Revocable by either party at any point.
• Never granted to somebody who already holds the counterpart authority, enforced by the system rather than by the good sense of whoever sets it up.
• Visible on the record, so the audit trail says on behalf of rather than silently recording the stand-in as the decider.
• Excluding the exceptional powers. An emergency override stays with its original holder; a stand-in gets the ordinary authority.

Without the last two you have a system where, after the fact, nobody can tell who actually decided something — which defeats the purpose of recording decisions at all. What that record has to contain is set out in what an audit trail is for.

The question to ask about every action#

For each thing a person can do in your system, four questions:

1. Who may do this? Stated as a rule, not as a list of names.
2. Is it reachable by more than one route? If so, does every route check?
3. What does it leave behind? An action that changes something and records nothing cannot be governed at all.
4. Can it be undone, and by whom? Frequently the undo is more powerful than the action, and is guarded less.

The fourth is the one people miss. Cancelling a receipt is a bigger capability than creating one, because creating a wrong receipt is visible and reversing a correct one is not. Put to somebody else's system rather than your own, the same enquiry takes the shape of approval chains worth asking about.

The short version#

Visibility and authority are different axes, and merging them forces you to choose between over-privileged people and blind ones.

Check the right property rather than the primary role. Enumerate every door into a capability, not just the one it was built behind. Give the same refusal whether a record is missing or forbidden. Make powerful capabilities explicit grants that one screen can show and one action can withdraw.

And when authority is delegated, bound it, record it as delegated, and never let one person end up holding both halves of a rule that exists to require two.

That is a small part of it, and it is the part that makes audit trails unpopular with the people who have to work under them. The larger and more useful purpose is reconstruction: being able to say, later, what the state of the world was at a particular moment and what somebody knew when they acted.

Framed that way, the audit trail protects the person who made the decision at least as much as it protects the organisation.

The question it exists to answer#

Not who did this. The much harder question is:

Why was this reasonable at the time?

A decision made a year ago was made on information available a year ago. If your records only hold the current state, then every past decision is judged against facts that arrived afterwards, and every past decision looks worse than it was.

An audit trail that captures the state at the time of the decision — what the order said, what had been received, what the balance was, which version of the document was signed — makes the reconstruction possible. Without it, defending a correct decision is a matter of memory and confidence.

What has to be in an entry#

Five things, and the fourth is the one usually missing.

Who. Including, where relevant, on whose behalf. A delegated action recorded under the stand-in's name loses the fact of delegation permanently.

When. Server time, not client time. A client clock is under somebody's control.

What changed. Both sides — the value before and the value after. A trail that records only the new value cannot answer the most common question, which is what it used to be.

Why. A reason, where one is required. This is the field that turns a log into a record, and it is the one systems skip because it needs a human.

On what basis. Which version of the document, which rule, which computation. A payment approved against a total that has since been revised needs to record the total it was approved against.

The reason that never arrived#

A concrete failure from our own system, because it shows how easily the fourth field is lost.

Reversing a stock entry required a reason, and the interface asked for one. The reason never reached the audit trail — because the trail reads the reason from the record's new state, and no reason was ever handed to it.

So every cancellation would have been recorded as having happened for no stated reason. The prompt was there, the person typed an answer, and the answer went nowhere.

Nothing errored. The trail was full of properly formed entries, each complete except for the only field anybody would ever want. This is the ordinary shape of audit-trail defects: they do not look like failures, they look like records.

Append-only, or it is not a trail#

An audit trail that can be edited is a document, not a trail.

This is not a matter of degree. If the entries can be revised, then the trail tells you what somebody most recently wanted it to say, which is precisely the thing you were trying to avoid depending on.

The practical form is that entries are only ever added. A mistake in the trail is corrected by a new entry describing the correction, not by fixing the old one. The full argument, including why this is also better for ordinary day-to-day questions, is in append-only records.

Ours is a hash chain, which means each entry incorporates a fingerprint of the one before it. The practical consequence is that no entry can be inserted, removed or altered without breaking every entry after it — including by somebody with database access. It also means a hand-written entry is impossible, which is a constraint we ran into and then decided to keep.

What it must not become#

Three failure modes turn an audit trail into an expense with no benefit.

A log of everything. If every read, every page view and every keystroke is recorded, the trail is enormous and the decisions are buried. Record the decisions and the changes, not the traffic.

A trail nobody can read. A table of field names and identifiers is technically complete and practically useless. If answering an ordinary question requires an engineer, then the trail is not available to the people who need it, and its existence is theoretical.

A trail that is only consulted in disputes. A record read once a year is a record nobody notices is broken. Ours had a missing reason field for a long time precisely because nothing routinely depended on it.

The remedy for the third is to make the trail part of ordinary use. If the history of an order is visible on the order — who did what, when, why — then people read it weekly, and defects in it get noticed by users rather than by auditors. If you are buying rather than building, that is also the thing to make a vendor show you — ask to see the audit trail before you sign.

It protects the approver#

Worth stating separately, because it changes how people feel about being recorded.

Somebody who approved a payment correctly, on the information available, should be able to demonstrate that in two years. Somebody who signed a document should be able to show which version they signed. Somebody who accepted a delivery should be able to show what they recorded on the day.

Without a trail, all of those people are relying on their own recollection and on the goodwill of whoever is asking. With one, they have evidence — and what that evidence has to consist of when a department or an auditor asks years later is the paper trail a query demands.

That is a large part of why people are willing to sign things at all, and it is worth saying out loud when a trail is introduced — because the alternative framing, that the system is watching them, is both available and corrosive.

The related question of the document itself#

An audit trail records what happened to a record. It does not, by itself, prove that a document is the document that was signed.

That is a different mechanism — tamper-evident documents — and the two are complementary. The trail says a signature was applied at a time by a person. The document's own fingerprint says this is the thing that was signed.

The short version#

An audit trail exists so that a past decision can be reconstructed, including by the person defending it.

Record who, when, what changed on both sides, why, and against which version. Make it append-only, or it records only the most recent intention. Keep it small enough to be readable and visible enough to be read routinely.

And check, in your own system, that the reason field actually arrives. Ours did not, for a long time, and every entry looked perfectly fine.

You can change it. Or you can add a new entry that says the old one was wrong, by how much, and why.

The first is simpler, produces a tidier screen, and destroys the ability to answer almost every question anybody will later ask. The second costs one extra row.

What an edit actually removes#

When a stored value is overwritten, three things go with it.

What it used to be. Obvious, and the least important.

That it ever changed. This is the real loss. A value that was corrected looks identical to a value that was right the first time, so the fact of the correction — which is often the interesting event — leaves no trace.

Everything that was decided while the old value was in place. Somebody approved a payment against a total. Somebody ordered material against a quantity. Those decisions were reasonable given what was on the screen, and after an edit there is no way to show what was on the screen.

The third is why this is a governance matter and not a database preference. An edited record makes past decisions indefensible, including correct ones.

The shape of an append-only correction#

Do not change the entry. Write another one.

For a stock entry: the original marked cancelled, and a reversing entry of the opposite sign. For a payment: a reversal and a fresh entry. For a quantity: an adjustment with its own date and reason.

There is a detail in the stock version worth borrowing generally. Our reversal writes two halves in one movement: the original marked cancelled, and a reversing correction of the opposite sign which is itself born already cancelled.

That shape is deliberate. A reader that filters out cancelled rows sees neither half. A reader that forgets to filter sees both, and both add to zero. The answer is correct under either reading — which is what you want when you cannot personally audit every piece of code that will ever count your stock.

It is also keyed so that a second reversal of the same entry is impossible, which closes the obvious way to turn a correction into a hole.

The objection, and the answer#

The objection is always the same: the screen gets cluttered. Nobody wants to look at a list of transactions where half the rows are cancelled.

The answer is that presentation and storage are different problems. The default view can show the net position and nothing else. What matters is that the history exists underneath it and can be reached by anybody who needs it, without an engineer.

An append-only ledger with a clean default view is strictly better than a mutable one. An append-only ledger with no view at all is worse, which is why the presentation work is not optional and is usually where these projects fail.

Where the discipline has to hold#

Financial records, obviously.

Stock movements, because a physical balance is the sum of its history and an edited history produces a balance that cannot be explained.

Anything with a reason attached. A write-off, a deduction, a rejection. The reason is the record — the amount is arithmetic anybody could recompute. We refused, deliberately, to allow a payment schedule containing written-off stages to be deleted, because deleting it would take with it every recorded reason for every write-off on it, and those reasons are the only surviving answer to who decided that money would never come.

Approvals and signatures. These attach to a state of the world; if the state can be changed afterwards, the approval means nothing.

The audit trail itself, absolutely and without exception — which is really the same statement, since the trail is the append-only record of everything else.

The trail that cannot be written by hand#

Ours is a hash chain: each entry incorporates a fingerprint of the one before it. Alter, insert or remove an entry and every entry after it stops verifying.

There is a consequence of that which we did not anticipate and have decided to keep. No audit row can be written by hand. Not by a developer with database access, not by an administrator fixing something, not by a migration script. The chain either was produced by the application's own recording path or it does not verify.

That is inconvenient about twice a year. It is also the property that makes the trail worth anything, because a trail that a sufficiently senior person can adjust is a trail that says whatever that person wants it to say.

Derived values are the exception, and must be computed#

Append-only applies to facts. It does not apply to conclusions drawn from them.

A running balance, a total, a status — these should be computed from the entries, not stored and maintained. A stored derived value is a second copy of a fact, and second copies drift.

We learned this expensively. A payment total, a paid flag and a schedule of stages all described the same money, and the flag was never written by the staged path. Nine separate places in the application asked the flag rather than the schedule, each written by somebody who reasonably assumed it meant what it looked like it meant. The account is a fact that had no owner.

So: entries are appended and never edited; conclusions are computed and never stored. Where a stored conclusion is unavoidable for performance, exactly one piece of code should own it, and everything else should ask that code.

What it costs#

Storage, which is free. A little more work at presentation time, which is real. And a genuine discipline problem: somebody will always want to make a bad row disappear, and the honest answer is that they cannot, only that they can correct it visibly.

One further cost is easy to defer and expensive to discover: a history is only yours if it survives the day you leave the system, and most exports carry the current values and none of the corrections — getting your data back out.

That last one is the whole point and the reason it needs to be a rule rather than a preference. A system where the right people can quietly erase things is a system whose records are worth what those people's memories are worth.

The short version#

Correct by adding, never by overwriting.

Write reversals in a shape that reads correctly whether or not the reader filters out cancelled rows. Keep reasons, and refuse to delete anything that carries them. Compute totals rather than storing them. And make the audit trail structurally impossible to write by hand.

Then show a clean view on top of all of it, because a history nobody can read is a history nobody will maintain. What that history has to contain is set out in what an audit trail is for.

There is no way to prevent that. Once a copy exists outside your control, it is theirs to modify. The useful goal is not prevention — it is detection: making it so that any alteration can be demonstrated, by anybody, without having to trust the person holding the copy.

That distinction is worth being precise about, because "tamper-proof" is the word people reach for and it promises something no system delivers.

What tamper-evidence actually requires#

Three things, and each one has an obvious wrong implementation.

A fingerprint of the exact bytes. A cryptographic hash of the finished document. Change one character and the fingerprint changes completely. This is the mechanism, and it only works if the fingerprint is of the final document — including every signature mark, every stamp, every appended page.

A way to check that fingerprint against a copy you did not produce. A number printed on the page is useless unless a person holding the paper can verify it against something authoritative. In practice that means a URL, and a QR code so the URL can be reached from a printed page without typing.

A record on your side that says what the fingerprint should be. Kept append-only, because a fingerprint register somebody can edit is a register that certifies whatever the last editor wanted.

Where the marks go, and why the order matters#

There is an ordering constraint here that is easy to get wrong and hard to recover from.

Signature marks have to be drawn first, and the whole document sealed and fingerprinted afterwards. Sealing first and then adding signatures produces a fingerprint of a document that no longer exists.

Stated like that it sounds obvious. It is not obvious when the signing feature and the sealing feature are built at different times by different people, and the natural order of implementation is the reverse of the correct one.

The same applies to every page. Fingerprinting only the last page — the one with the signature on it — leaves every other page of the document unprotected, which is a substantial gap on any document longer than one sheet. A work order whose last page is provably genuine and whose middle pages can be replaced is not tamper-evident in any useful sense.

The strip at the foot of every page#

The practical implementation we settled on puts a reserved strip at the bottom of every page carrying four things: the document number, page N of M, the fingerprint, and a QR code that reaches the verification page.

Each of those four is doing a specific job.

The document number identifies which document this claims to be.

Page N of M is what makes page removal detectable. Without it, deleting a page from the middle produces a shorter document that is otherwise entirely plausible.

The fingerprint is the check itself.

The QR code is what makes the check available to somebody holding paper, which is the only situation in which any of this matters. A verification mechanism that requires the verifier to already be inside your system verifies nothing for the people who need it.

The strip is reserved, visibly, at the point where somebody chooses where a signature goes, and again on the server when the document is produced. A signature laid over that strip would hide the four things that would have to be forged together, and a rule enforced only in the interface is a rule that applies until somebody uses a different route.

Sealed means sealed#

Once a document is signed and sealed, it cannot be overwritten from the editor it came from. Editing hands you a copy, and the original that the verification page vouches for stays byte-for-byte what it was.

This is the part users push back on, and the pushback is reasonable — they want to fix a typo. The answer has to be no, and the reason has to be explained rather than enforced silently: a document whose contents can change after signature is a document whose signature means nothing, including the signatures that were applied in good faith.

Giving them a copy immediately, in one action, removes most of the friction. Refusing without offering the copy is how a control gets routed around.

The awkward details that decide whether it works#

Rotated pages. A page carrying a rotation instruction is rendered one way by the tool that displays it and another way by the library that writes marks onto it. If those two disagree, a signature placed in the right place on screen lands somewhere else in the file. Our picker refuses a placement on a rotated page rather than guessing, because a signature in the wrong place on a legal document is worse than a refusal.

Which page each mark is on. The accompanying record page states where every signature was placed, so somebody holding the last sheet can still find the middle one.

The verification page itself. It has to say what it checked and what the answer means, in plain words. This document matches the record and this document does not match the record, here is what we hold are both useful. A green tick with no explanation teaches people nothing and is trusted for the wrong reasons.

What it does not do#

Tamper-evidence proves that a document is byte-for-byte what was signed. It does not prove the contents were true, that the signatory understood them, or that the signatory was who they said they were. Those are separate questions with separate mechanisms, and conflating them is how people end up over-relying on a technical control. What a signature applied on a phone does and does not prove is one of them — signing a document from a phone.

It pairs with, rather than replaces, a record of what happened — what an audit trail is for. The trail says a signature was applied at a time by a person. The fingerprint says this is the thing that was signed. You need both.

And both depend on the underlying records being append-only, because a fingerprint register that can be revised certifies nothing at all.

The short version#

You cannot stop somebody editing a copy. You can make the edit provable.

Fingerprint the final bytes, after the marks are drawn, on every page not just the signed one. Print the document number, the page count, the fingerprint and a QR code where a person holding paper can use them. Reserve that space properly, on the server as well as in the interface.

Refuse to overwrite a sealed document, and hand over a copy in the same breath so the refusal does not become an obstacle worth defeating.

A machine may look at a bank transaction and conclude it paid a particular invoice. It may look at a photograph of a delivery slip and conclude it belongs to a particular order. It may look at two tasks and conclude they are the same piece of work.

In every case the conclusion is recorded as a suggestion. A person taps to confirm or to reject. Only the tap makes it a link. Merging two records that appear to name the same buyer is the same act with more at stake, because it also settles whose enquiry it is — one buyer, three enquiries.

Why, given that the machine is usually right#

The objection is reasonable. If the match is correct nine times out of ten, insisting on a tap costs nine unnecessary actions to prevent one error.

The answer is that the cost of the tenth is not what it appears to be.

An automatic link produces a record that is indistinguishable from a human decision. Six months later somebody reads this transaction paid that invoice and has no way of knowing that nobody ever agreed. They act on it. They reconcile against it. They tell a vendor something based on it.

The error is not the wrong pairing. The error is the false confidence in the record afterwards, and that confidence is unbounded — it propagates into every decision downstream, and none of those decisions carry a marker saying they rested on a guess.

A wrong suggestion, by contrast, is refused in two seconds and leaves nothing behind.

Asymmetry, not caution#

This is not a general position that machines should be distrusted. It is a specific observation about asymmetric costs.

The cost of asking is small, bounded, and paid immediately by somebody who has the context. The cost of a wrong automatic action is unbounded, paid later, by somebody who does not.

Whenever costs are shaped like that, the answer is to ask. Where they are not — where a wrong action is cheap and easily reversed, and asking is expensive — automate freely. Sorting, ranking, filtering, drafting, extracting, summarising are all fine. It is asserting a fact into the record that requires a person.

What we had to undo#

When we adopted the rule, some links had already been created automatically by the machine's own authority.

We converted them back into suggestions, in the same migration that introduced the rule.

There was no honest alternative. A record created by a mechanism you have since decided is not trustworthy does not become trustworthy by being a few weeks old. Leaving them would have meant a permanent stratum of records that looked like decisions and were not, with no way to tell them apart afterwards.

That is an uncomfortable amount of work to take on for a principle, and it is the part that tells you whether the principle is real.

What a good suggestion looks like#

Six properties, learned mostly by getting them wrong.

It carries its reasoning. Not a score — a sentence. Exact amount, vendor name in the narration is something a person can agree or disagree with. A number out of a hundred is something they either believe or ignore. The general argument is the app should tell you why.

It meets an evidence floor. A weak guess is worse than no suggestion, because reviewing it costs the same as reviewing a good one. We found that a near-miss amount alone was being treated as evidence, and it is not — it is an absence of contradiction. It now needs corroboration beside it. The mechanics are in matching a bank line.

The same floor applies everywhere. We had a second surface offering the same kind of pairing, written separately, with its own lower threshold. So a match the main matcher would have refused was available as a one-tap action somewhere else. One rule, one implementation, asked by every screen.

Both answers are permanent. A rejection is remembered, so the same wrong pair is never proposed again. A suggestion system that forgets its rejections re-asks the same question weekly and is muted within a month.

It is reachable. Ours were not, for a while — the suggestions were being hidden by the very filter meant to rank them, and a related action existed as code with no button anywhere in the application. Built is not the same as reachable, which is its own piece: written, and never wired.

Undo is complete. Undoing an attachment must also close the open question it answered, or a stale card keeps rendering on a record the money never belonged to.

Where the line falls#

It is worth being concrete, because "propose, do not act" can be read as paralysis.

Machine acts freely: ranking a queue, extracting text from an image, transcribing speech, drafting a message, computing a total, flagging an anomaly, sorting by risk, filling a form field the person can see and change before submitting.

Machine proposes only: creating a link between two records, attaching money to an order, marking something paid, closing a task, sending a message to a person outside the company, changing a permission, writing to an audit trail on somebody's behalf.

The test is simple. If the action produces something a future reader would interpret as a decision, a person has to have made it.

It is also better for the machine#

An unexpected benefit: confirmations and rejections are training data.

A system that acts alone learns nothing, because it never finds out whether it was right. A system that proposes accumulates, with every tap, a labelled judgement from somebody who knew the answer. Ours uses confirmed matches to learn vendor labels, which improves later suggestions.

Asking is not the price of safety here. It is the mechanism by which the thing gets better.

The short version#

Never let a machine assert a fact into the record on its own authority.

Not because machines are unreliable, but because an automatic error is indistinguishable from a decision, and it will be trusted by people who cannot know it was never made.

Propose, with reasoning, above an evidence floor, from one implementation, remembering both answers, with a complete undo.

Then a wrong guess costs two seconds instead of a year.

A page refuses access. A list is empty. A field will not accept a value. A number appears with a colour. In each case the software knows the reason exactly, and in each case it has chosen not to share it.

The cost is not confusion in the moment. It is that people learn the system is arbitrary, and arbitrary systems get worked around.

The four places it happens#

A refusal. Somebody is not allowed to do something. The screen says so and stops. We had a refusal that landed people on a blank form with no indication of why they had got there. They had done nothing wrong and there was nothing for them to do differently; they simply learned that the thing sometimes does not work.

An empty state. A list with nothing in it looks identical whether it is empty because there is nothing to show, empty because a filter is excluding everything, empty because the data has not loaded, or empty because something upstream is broken. Four completely different situations with one appearance. A layer that is switched on and holding nothing should say so rather than looking indistinguishable from one that was never switched on.

A computed judgement. A risk score, a suggested match, a flag. Without its basis, the number is either believed blindly or ignored entirely. Neither is use.

A thing that happened by itself. A calendar entry that appeared, a message that was sent, a task that moved. If the system does something on a person's behalf and does not say what caused it, the person's reasonable conclusion is that the software is unpredictable.

None of the four appears in a sales demonstration unless somebody asks to see one, which is why how to run a software demo is largely a list of things to insist on.

Why it goes missing#

Not because anybody decided against it.

The reason exists at the point of the decision, deep in some function that knows exactly which condition failed. Then the result travels outward as a boolean — allowed or not, matched or not, valid or not — and by the time it reaches the screen the reason has been thrown away several layers earlier.

Recovering it is not a design task, it is a plumbing task, and plumbing tasks lose to features in every prioritisation meeting ever held. That is the actual mechanism, and knowing it is useful because it tells you where to fix it: the reason has to be carried, not reconstructed at the end.

What a good "why" contains#

Three parts, and most implementations stop after the first.

What happened. This is refused.

Why, specifically. Not a category. The actual condition: because this order is closed, because your account does not hold the export key, because the material has not been received against this payment.

What to do about it. The part that turns an explanation into help. Who to ask, which button, what has to happen first. A refusal that names the person who can grant the thing removes an entire support conversation.

We rewrote a set of failure notices in our own system that had all three parts wrong. When a message failed to send, the notice told people to create an approved template in a service we had retired months earlier — so it was sending people to fix a problem that could not exist. Its sibling was worse: when a handset stopped answering, the notice said messages were being routed via the other provider. There is no other provider. They were not being sent at all.

Both now describe the system that is actually running and name the real cause — the handset needs re-pairing, the secret no longer matches, nothing is answering, or the service was too busy to reply — each with the one action that fixes it.

Explanations in the reader's language#

An explanation in a language the reader does not use is not an explanation.

This matters more than it sounds on an Indian construction site, where the person receiving a refusal may read Hindi and not English, or may read neither comfortably. Our approach is one plain line in the reader's own language, with the original text kept beside it rather than replaced — because the original is what somebody technical will need if the plain line turns out to be wrong.

And the register matters as much as the language. In Hindi, the respectful form throughout, never bare imperatives. A system that instructs people curtly in their own language is worse than one that does it in a foreign one, because the rudeness lands.

Explaining without being noisy#

The obvious objection is that explanations clutter the screen, and it is a fair one.

Three rules keep it manageable.

Explain the unexpected, not the ordinary. A successful save needs no justification. A refusal always does.

Put the reason where the effect is, not in a separate log or a tooltip nobody hovers. If a payment is held, the reason belongs on the payment.

Keep it to one sentence in the interface, with the detail one tap away. Most people need to know why; a few need to know precisely why.

The pin that explains itself#

A small example we are fond of, because it shows the idea working at a scale where it clearly costs nothing.

A public portal existed with no explanation of what it was for, so it looked arbitrary to anybody who came across it. Adding one line — what this is and why it exists — turned an unexplained thing into an understood one, permanently, for the price of a sentence.

Almost every "why" in a system is that cheap. The expensive part is noticing which questions people are silently asking.

Where it connects#

An unexplained judgement is the failure mode of every predictive feature. A slip warning without its basis is a number people stop reading, which is why work slips before it is late insists on the sentence rather than the score.

An unexplained proposal is the failure mode of every suggestion system, which is why every match in our own tools carries its reasoning — the machine proposes, a person decides.

And an unexplained routing decision is how a signature request ends up delivered as chatter, in filed as chatter.

The short version#

The system always knows why. It just discards the reason on the way out.

Carry it. Say what happened, why specifically, and what to do next. Say it where the effect is, in the reader's language, in a respectful register, once.

An unexplained refusal is not a small usability flaw. It is the thing that teaches people the software is arbitrary, and everything they do after learning that is a workaround.

It was made once, early, in the abstract, by somebody who was not thinking about the specific case it would eventually govern. It then applies to everything that falls into its category, for years, without being revisited — because nothing about it ever looks like a choice again. It looks like the way things are.

That property is what makes defaults the most under-examined part of any system.

How a default stops looking like a decision#

At the moment it is set, everybody involved knows it is a judgement call. There is often a discussion. Somebody says we can change it later.

Then time passes. The people who set it move on. New behaviour is built on top of it and inherits it. New cases are classified into the category it governs, by people who are thinking about the classification and not about what the classification implies.

And the default becomes invisible, in a specific way: it is not that people disagree with it, it is that they no longer see it. When something goes wrong, nobody looks there, because it does not present as a place where a decision lives.

What it looked like for us#

A document was sent for signature. It sat there. The person who had to sign did not know they had to sign it.

The request went out carrying a generic type — question — and types are mapped onto rows in a routing grid. Question had been mapped, sensibly enough, onto the row for comments. And the comment row's default delivery is a bulletin: held back until the next scheduled broadcast, ringing nothing, arriving as one line among a dozen others that also did not need doing right now.

So a document that was holding up a payment was delivered as chatter.

Every component in that chain did its job. The request was raised correctly. It was classified into a real category. That category was routed by a rule somebody had written down on purpose. Nothing failed. The design had simply never been asked what a signature request is, so it answered a different question and answered it well. The full account is filed as chatter.

The blanket rule and what it hides#

The second thing defaults do is more subtle and, in our experience, more dangerous: a blanket rule hides which places were depending on it.

We had a single line of styling that put the entire application into capital letters. It was doing what was asked. It was also, inevitably, capitalising things nobody had meant to capitalise — names, comments, error messages.

When we came to remove it, we found that 129 of the application's 138 table header cells carried no case rule of their own. For as long as the blanket existed they never needed one. So simply deleting the blanket would have quietly un-capitalised every column heading in the application — which the newly written rule says should be capitalised.

Every place that stopped declaring its own intention because a blanket was covering it becomes invisible, and stays invisible right up until the blanket comes off. Removing a default is a survey, not a deletion, and the survey is the whole job. That story is capitals are a contrast, not a volume.

Defaults that are actively harmful#

Some default choices are worse than others in a way worth naming.

A default that fails silently. Anything where the wrong outcome produces no error. A message delivered quietly rather than loudly. A field defaulting to zero rather than to unknown — we made a phone's step count nullable rather than zero precisely because no phone reported and the person did not move are different facts.

A default that is correct for the common case and catastrophic for the rare one. These are the hardest, because the default is right and the exception is what needs attention. A notification tier that is correct for comments and disastrous for signature requests is exactly this shape.

A default set for a system that no longer exists. Configuration outlives architecture. We had failure notices instructing people to fix things in a service we had retired months earlier, and they had been sending people to solve an impossible problem ever since.

Quiet is a feature#

An important corollary, because the reflex when a default is found to be wrong is to make everything louder.

Loudness is a resource with a fixed supply. An application that rings for everything is an application people mute, and a muted application delivers nothing at all. The bulletin tier in our own system is doing real work for the messages that genuinely belong to it — the mistake was never that quiet delivery exists, it was that a signature request had been classified into it.

So the fix is not escalation. It is to stop lying about what the message wants. Once a request says this asks somebody to act, the routing follows on its own and nobody has to argue about priority. That reasoning is in an alert that rings for everything.

How to audit your own#

Four questions, applied to any default worth the time.

1. When was this set, and by whom, and for what case? If nobody knows, that is itself the finding.
2. What is now classified into this category that was not when it was set? The category grew. The default did not.
3. What happens when it is wrong? A default whose failure is loud is much safer than one whose failure is silence.
4. What would break if it were removed? Not what would change — what would break. That question is the survey, and the answer is usually longer than expected.

The fourth is the one people skip, and it is the one that costs the regression.

The same four are worth asking of a system you are about to buy, where the defaults are somebody else's and you inherit every one of them — how to choose construction software.

The short version#

A default is a decision made once, in the abstract, that then applies for years without ever looking like a decision again.

The dangerous ones are the ones that are right for the common case, silent when wrong, and covering places that stopped declaring their own intention because the default was covering them.

Removing one is a survey. And when a default turns out to be wrong, the answer is usually to fix the classification rather than to turn up the volume.

That part is straightforward and it is not where the difficulty is. The difficulty is that a record created offline is a different kind of record, and every rule that governed the online version has to be re-examined against it.

What changes about a record#

An entry created against a server was created in a conversation. The server saw the request, applied its rules, and the result was known immediately to both sides.

An entry created offline is an assertion made by a device, in isolation, about a moment nobody else observed, delivered later. Three things about it are now claims rather than facts:

Time. The device clock is under the user's control.

Sequence. Two devices offline at once will produce events whose true order nobody recorded.

Validity. The rules were not applied when the entry was made. They will be applied when it arrives, which may be after the situation it referred to has changed.

None of these has a general solution. Each has to be decided for the specific record.

Decide time explicitly#

The commonest mistake is to store one timestamp and never say which one it is.

Store both: the time the device claims and the time the server received it. They are different facts, and the gap between them is informative — a large gap is ordinarily a queued punch and occasionally an altered clock.

Then decide, per record type, which one governs. An attendance punch should almost certainly use the claimed time, because the whole point is when the person was there. A financial entry should almost certainly use the server time, because the ordering of money matters more than the device's opinion. What must not happen is that the decision is made implicitly by whichever field somebody selected.

Decide the rules that cannot be checked offline#

Some rules can be applied on the device: this field is required, this number must be positive, this date must be in the past.

Others cannot, because they depend on state the device does not hold: is this person still employed, is this site still active, has somebody else already recorded this, is the order still open.

The offline design has to answer, in advance, what happens when an entry passes the device's checks and fails the server's. There are only three honest answers: accept it anyway with a flag, reject it and tell the person, or hold it for somebody to resolve. All three are defensible. Not choosing means the behaviour is decided by an error handler somebody wrote in a hurry.

Related, and vital: the device must be able to tell try again later from stop retrying this one. Without that distinction a permanently invalid entry retries for ever, draining a battery and filling logs. We marked our payload refusals explicitly as permanent for exactly this reason. The detail is in attendance on a site with no signal.

Deduplicate on an identifier, not on content#

A poor network is not one that fails. It is one that succeeds after the client has given up, so the same entry arrives two or five times.

Fold them by an identifier generated on the device at the moment of creation, carried with every retry. Deduplicating on content — same person, same time, same amount — is wrong in both directions: it merges two genuinely separate events that look alike, and it fails to merge one event whose details were recomputed between attempts.

Authenticate the device, never the message#

If the payload says who it is from, then anybody who can reach the endpoint can be anybody.

Our devices carry their own credential, issued once during an ordinary sign-in inside the app, shown once and stored only as a hash. A queued entry authenticates as that device, and the identity is derived from the credential rather than read from the message.

Two consequences worth planning for. A credential can be revoked, and revocation has to reach the queue — entries already queued on a revoked device should not be honoured simply because they were created before it was revoked. And the emergency stop has to cover this door too: a lock that stopped every screen while phones went on posting would not have stopped anything.

One law, two doors#

The strongest structural rule, and the one most often broken: an offline entry must go through the same function as an online one.

Not a similar function written for the device's convenience. The same one, with a different authentication route into it.

The temptation to write a separate, simpler path is strong, because the device's needs are different and the shared function has awkward edges. It is the same temptation that produces two implementations of any rule, and the result is always the same — they agree at first, they drift, and the drift is silent because each is internally consistent. That is the failure described in a fact that had no owner.

Signals are not activities#

A phone that is offline can still observe things — position, movement, battery. It is tempting to let those observations count toward whatever the record is measuring.

We drew a hard line: a background position sample is a signal, not an activity. It never counts toward the presence window, never counts as activity, never decides which site somebody was at, and never grants access to anything. It is recorded only while the person is deliberately punched in, and the server enforces that rather than the app.

The reason is that a figure derived partly from deliberate acts and partly from ambient observation is a figure nobody can explain. When somebody disputes it, you need to be able to say what was recorded and by whom.

Test the ugly cases, because they are the common ones#

The demo path — go offline, make an entry, come back, see it sync — always works, which is why how to test a works-offline claim in ten minutes is a cheap phone in flight mode rather than a meeting. The ones that matter:

• Entry made offline, and the underlying thing changes before it syncs.
• Two devices offline making conflicting entries about the same object.
• Device offline for a week.
• Device clock wrong by hours.
• Sync interrupted halfway.
• Credential revoked while entries are queued.
• Same entry delivered five times.

Each of these is ordinary in the field and absent from every test plan written at a desk. The general point — that the test is the worst day, not the demo — is in how we find our own problems.

The short version#

Offline is not about the network. It is about what a record means when it was created by a device nobody was watching.

Store claimed and received time separately and decide which governs. Say in advance what happens when server rules reject an entry the device accepted. Deduplicate on an identifier created at source. Authenticate the device, not the message. Keep observations distinct from acts.

And send both routes through one function, because two implementations of a rule is two answers waiting to disagree.

That is a small problem for a form label and a large one for anything that has to recognise what somebody wrote.

Four words that matched two captions#

Our system recognised a photograph from site as a delivery record only if its caption contained one of four words: challan, bilty, GRN, delivery.

Those are the correct words. They are what the document is called. They appear in the purchase manual, in the training material and on the form.

Measured against four hundred real captions the site team had actually sent, those four words matched two.

What people really write is the material, a quantity and a unit — a concrete grade with a volume and a weight. Or the vehicle: a supplier's mixer has arrived. Or a plain numbered list: a trader's name, then two lines each with a quantity and a unit.

Nobody was refusing to use the official word. They were describing what had happened, in the way a person describes something to a colleague, which is the only way anybody writes when they are not filling in a form.

Reading those three shapes instead — the material named directly, the vehicle that brought it, or any quantity with a unit — took the match rate from two to thirty-four out of the same four hundred captions. Nothing about the site changed.

Why the official word is never the used word#

Three reasons, and none of them is carelessness.

The official word is a category; the used word is the specific thing. Nobody says "a delivery has arrived". They say what arrived.

The used word is shorter. Effort matters enormously when your hands are dirty.

The used word is often not in the interface language. A person typing on a site in India may write in Hindi, in Devanagari or in Roman letters, or mix both in one sentence. A vocabulary list that contains only English words has excluded a large fraction of the input before it starts, and what a supplier's promise of Hindi support usually turns out to mean is examined in software your staff can actually read.

Where vocabulary decides behaviour#

It is worth separating the places where this matters from the places where it does not.

Labels on a form. Matters a little. People adapt.

Search. Matters a lot. Somebody searching for a material by the name the site uses, in a system that stores the purchasing name, finds nothing and concludes the record does not exist.

Recognition of free text. Matters completely. This is the case above, and it is the difference between a feature working and a feature that has never once fired.

Error messages and refusals. Matters completely, and in a different way — a message in a vocabulary the reader does not have is not a message. That is part of the app should tell you why.

How to find the real vocabulary#

Not by asking. If you ask people what words they use, they will tell you the official ones, because a question about vocabulary sounds like a test.

Read what they have already written. Every organisation has a large corpus of real language sitting in its message history, its site diaries, its comment fields and its photograph captions. Take a few hundred, read them, and count.

Two rules make this useful rather than merely interesting.

Measure against real examples, not against intuition. Our four words felt comprehensive. Counting them against four hundred captions is what produced the number two, and no amount of discussion would have.

Keep counting afterwards. Vocabulary drifts, new materials arrive, staff change. A recognition rule that was measured once, three years ago, is a rule whose accuracy is now unknown.

Broadening without becoming wrong#

The obvious risk in accepting more vocabulary is accepting the wrong things.

Our matcher still refuses what is plainly not a receipt: a cylinder going out for refilling, a truck that damaged a divider, a weight dispute. Each of those contains a material, a quantity and a vehicle, and each would be caught by a naive broadening.

Two things make the broadening safe.

Explicit exclusions, drawn from the same corpus. The non-cases are in the message history too, and they are the more valuable half of the reading exercise, because they are what tells you where the boundary is.

Everything is a suggestion. A match is proposed and confirmed with one tap, never filed automatically. That converts the cost of over-matching from a wrong record into two seconds of somebody's attention — which is what makes it possible to be generous with recognition at all. The argument is in the machine proposes, a person decides.

Respect is part of the vocabulary#

One more dimension, easy to miss if you only think about matching.

In Hindi, the difference between the respectful form and the bare imperative is not stylistic. A system that tells people what to do in the familiar imperative reads as rude, consistently, to everybody who receives it — and it is being read by people who are already the least powerful users in the organisation.

Our rule is the respectful form everywhere, without exception. It costs nothing and its absence is felt every single time.

What this is really about#

The general principle is one we keep arriving at from different directions: when the field has settled on a behaviour, the software's job is to read that behaviour rather than to replace it.

People photograph slips because a photograph is faster than a form. People send voice notes because their hands are dusty and the screen is in the sun. People write the material rather than the word "challan" because that is how a person describes a thing to another person.

None of that is going to change, and a system that requires it to change will be worked around by competent people who have real work to do. The wider version of the argument is in WhatsApp is the interface, whether you designed for it or not.

The short version#

The vocabulary in your software is the vocabulary of the people who wrote it.

Find the real one by reading a few hundred real messages and counting, not by asking. Include the languages and scripts people actually type in. Collect the non-cases as carefully as the cases.

And keep every match a suggestion, which is what makes it safe to be generous.

The alerts are useful. More things become alerts, because each addition is individually justified. The volume rises. People stop reading. Somebody proposes a priority flag. Everything becomes high priority, because everybody's own work is important. People stop reading the high priority ones.

At the end of it the system delivers nothing, and the organisation has spent a lot of engineering effort to arrive at silence.

Importance is the wrong axis#

The instinct, when a message is missed, is to reach for importance: mark it urgent, give it a red badge, put it higher in the list.

That fails for a structural reason. Importance is assessed by the sender, and every sender's own work is important to them. A scale on which everything can be placed at the top is not a scale. Within a few months the flag carries no information at all, and you have taught people to ignore the one visual signal you had.

The useful question#

The question that does work is not how important a message is. It is what it asks the reader to do, and there are only three answers.

• Nothing. You should know this happened. Read it whenever.
• Later. Look at this next time you are looking at things.
• Now. Somebody is standing still until you act.

That is a property of the message, determined by its type, not a judgement made by a sender about their own priorities. Which is exactly why it stays meaningful: nobody can inflate it.

A signature request is always the third. It is not information about work; it is a request for a specific person's hand, and until that hand moves a document, a payment and usually another human being are all stopped.

A comment on a task is almost always the first. A task assigned with a date next week is the second, and so is a follow-up owed to a customer, provided somebody put a date on it rather than an intention — follow-up is a schedule, not a feeling.

What went wrong for us#

A document was sent for signature. It sat there. The person who had to sign did not know they had to sign it.

The request went out carrying a generic type — question — and types are mapped onto rows in a routing grid. Question had been mapped, sensibly enough, onto the row for comments, whose default delivery is a bulletin: held back until the next scheduled broadcast, ringing nothing, arriving as one line among a dozen others that also did not need doing right now.

A document holding up a payment was delivered as chatter.

Every component in the chain did its job correctly. The design had simply never been asked what a signature request is. It now has its own type, sits on the row for things awaiting approval, and says plainly that it asks for an act. It arrives on its own and it rings. It also says which page of the document the signature goes on, because sign this without here is still a small piece of homework. The full account is filed as chatter.

Quiet is a feature#

The fix, when this surfaces, is almost never to make things louder.

Loudness is a resource with a fixed supply. An application that rings for everything is an application people mute, and a muted application delivers nothing at all.

The quiet tier is doing real work for the messages that genuinely belong to it. The mistake was never that quiet delivery exists — it was that a request for action had been classified into it.

So the repair is to stop lying about what the message wants. Once a request says this asks somebody to act, the routing follows on its own and nobody has to argue about priority.

Accuracy is the whole asset#

A separate failure, and the more expensive one.

A chaser in our system rang the finance team every few days about money that had already left the account, because a payment made in stages never wrote the field that meant this is paid.

Nobody reported it. That is the part worth sitting with. It is not that somebody noticed and was ignored. It is that a recurring reminder which is occasionally wrong teaches you to skim the whole class of reminder, and once you skim it, the one that matters costs the same as the ones that do not.

The chaser was not merely useless. It was spending the credibility of every other chaser in the building. An alerting system's accuracy is not a quality attribute to be improved over time — it is the entire asset, and a system that is right most of the time is worth close to nothing.

The underlying data fault is described in a fact that had no owner.

One event, one message#

A smaller discipline that matters more than it sounds.

A delivery failure in our system used to open one ticket per recipient. So a single five-minute outage during a message to eight people produced eight tickets, each needing its own manual close.

The outage was one event. It is now one ticket, with the affected recipients carried inside it.

Any alerting design should be checked for this: what happens when one cause produces many symptoms. Systems that alert per symptom flood at exactly the moment attention is scarcest, which is the worst possible timing. There is more on that in one outage, one ticket.

Tell the person who can act#

The last rule, and it is the one that most often gets a system used rather than disabled.

Six mailboxes in our estate had lost their permission to send, one of them for over a week, and they stayed broken because of who was being told. The failure raised a ticket for the IT team — but IT cannot reconnect somebody else's mail account. Only its owner can, from their own browser, with their own password.

So the ticket sat open while the person whose mail had quietly stopped flowing never heard a word.

The routing question is not only how loud. It is to whom, and the answer is whoever can actually do something. A correctly urgent alert delivered to somebody powerless is the same as no alert, plus a false sense that it was handled.

The short version#

Route by what a message asks the reader to do, not by how important its sender thinks it is. There are three answers and only one of them rings.

Keep the quiet tier, because it is what makes the loud one mean something. Make sure the alerts are right, because a chaser that is sometimes wrong spends the credibility of every other chaser you have.

Collapse many symptoms into one event. And send it to the person who can act, which is frequently not the person your escalation table names.

Eight tickets open. Each has to be read, understood and closed by hand. All eight describe the same five minutes.

This is not a rare pathology. It is the default behaviour of almost every system that raises alerts, because alerts are naturally written at the point of failure, and the point of failure is per-attempt.

Why per-symptom alerting is the default#

Nobody designs it. It emerges.

Somewhere in the code, a send fails. The person writing that code does the responsible thing and raises a ticket. It is one line, it is correct, and it is tested with a single failure.

In production, failures are not single. They are correlated — one dead service, one expired credential, one network partition — and every correlated failure takes the same path through that line.

So the number of alerts is proportional to the number of attempts during an outage, which is a function of your traffic rather than of the problem's size. A busy hour produces a hundred tickets for the same cause.

What the flood costs#

Manual closing. Somebody must close each one, and closing tickets teaches people that tickets are noise.

The real one is buried. During a flood, an unrelated genuine problem arrives and lands in the middle of ninety copies of something else.

The pattern is destroyed. Ninety tickets from one cause and one ticket from another cause look like a ratio, and any counting you do afterwards is wrong.

Attention is spent at the worst moment. The flood arrives exactly when somebody needs to think clearly about one thing.

Group by cause, carry the details inside#

The fix is to make the unit of alerting the cause, not the attempt.

One outage, one ticket. The affected recipients, records or attempts travel inside it as a list. If more failures occur while the ticket is open, they join it rather than creating siblings. The same discipline on a building is one snag, one row, rather than four reports of the same cracked tile — a snag list that actually closes.

Three implementation questions decide whether this works.

What is the key? What makes two failures the same event. Usually the service or resource that failed, plus a time window. Getting this too narrow reproduces the flood; too wide and genuinely different problems merge.

When does the ticket close? Ideally on recovery, automatically, with the duration recorded. A ticket that must be closed by hand after the problem has gone will be closed late or not at all.

What if the cause changes? A ticket that stays open for a week accumulating unrelated failures is worse than a flood, because now nothing is separable. A time bound on grouping is necessary.

The ticket has to describe the system that exists#

A related failure, and in some ways a worse one, because the ticket count is fine and the content is wrong.

Our own message-delivery tickets used to tell people to create an approved template in a service we had retired months earlier. That service was gone. The bridge that replaced it has no templates and no approvals. So the ticket had been sending people to fix a problem that could not exist.

Its sibling was worse. When a handset stopped answering, the ticket said messages were being routed via the other provider. There is no other provider. They were not being sent at all — and the ticket's wording actively reassured whoever read it.

Both now describe the system that is actually running, and each names the real cause with the one action that fixes it: the handset needs re-pairing, the secret no longer matches, nothing is answering at the address, or the service was too busy to reply.

The general lesson is that alert text ages faster than alert logic. The condition that fires the alert gets maintained because it breaks visibly. The sentence describing it does not, because a wrong sentence produces no error. A message describing a system that no longer exists is a silent, permanent misdirection, and it is worth explicitly re-reading alert text whenever architecture changes. The wider argument is in the app should tell you why.

Tell the person who can fix it#

Grouping correctly and describing correctly still fails if the ticket goes to the wrong desk.

Six mailboxes in our estate had lost their authorisation to send, one of them for over a week, and they stayed broken because of who was being told. The failure raised a ticket for the IT team — but IT cannot reconnect somebody else's mail account. Only its owner can, from their own browser, with their own password.

So the ticket sat open while the person whose mail had quietly stopped flowing never heard a word.

Now the owner is told directly, with a one-tap link that starts the reconnect and an explanation of why it happened — usually a password change, which revokes the permission by design. IT still gets its ticket for the record.

That is the right shape: the actionable notification goes to whoever can act, and the record goes to whoever needs the record. They are different messages with different purposes and they should not be the same message sent to a list.

Silent failure is the worse cousin#

Everything above is about too many alerts. The opposite failure is quieter and more expensive.

A classifier in our system asked a small local model, in words, for a JSON array, and hoped. It got prose wrapped around the answer, or ran out of room mid-array and stopped before the closing bracket. It failed twenty-nine times over twenty-four days, quarantined real mail, and opened a ticket each time.

Twenty-nine tickets is a flood by the standards of this article, and it was still the good outcome, because the alternative — discarding the mail quietly — would have been invisible.

The eventual fix removed the failure rather than the alert: constrained decoding, where anything but valid output is impossible to produce. That is always the better order. Suppressing an alert because it is noisy, without fixing what it is reporting, converts a loud problem into a silent one.

The short version#

Alert on causes, not on attempts. One outage, one ticket, with the affected items carried inside it and an automatic close on recovery.

Re-read the words in your alerts whenever the architecture changes, because alert text ages faster than alert logic and a wrong sentence produces no error.

Send the actionable message to whoever can act, and the record to whoever needs a record.

And when an alert is noisy, fix the thing it is reporting before you quieten it. The related discipline of routing by what a message asks somebody to do is in an alert that rings for everything.

It is one of the most useful things you can do — the history becomes searchable, connected and usable. It is also one of the few operations that can quietly corrupt a working system in a way nobody notices for months, and the difference between the two outcomes is decided entirely before the write.

The two properties that make it safe#

Idempotent. Running it twice writes nothing the second time. This is what lets you run it, check it, and run it again after a fix without producing duplicates.

Reversible. Every row it wrote can be identified and only those rows. This is what lets you undo it if the check afterwards finds something wrong.

Both come from the same mechanism: tag every imported row with a marker that identifies the import and the source row. Ours was a short prefix plus the source document's own reference. That single field makes the second run write nothing, and makes the reversal an exact selection rather than a query somebody constructs afterwards from dates and hope.

Add it before the write or you will not add it at all, because after the write the rows are indistinguishable from everything else.

Reconcile before you write#

The rule we hold to hardest here: a parse that cannot reproduce the total it claims is not a parse anybody should import.

When we brought eight months of a concrete register into our own system, the verification was that the parsed rows had to reproduce three figures exactly — the row count, the total volume, and the total value — against the figures the register itself claimed.

They did not, at first. Two rows were missing: one with a blank serial number and one whose serial had been typed as a letter. Together they accounted for the discrepancy. Both were hunted down before a single row was written.

That check is worth more than any amount of spot-inspection afterwards, for a simple reason: a spot check confirms that the rows you looked at are right. A total confirms that the rows you did not look at are there.

If your source has no total to reconcile against, compute one from the source before parsing, by a different method, and reconcile to that. The point is two independent routes to the same number.

Decide the overlap deliberately#

The most dangerous part of any historical import is where the old records overlap the period the live system was already recording.

We had exactly this. Fifty-two rows in the register covered dates the live system had already been capturing through a different route. The register held one set of figures for those days; the system held another, smaller set.

They describe the same concrete, counted differently. Importing on top would have double-counted on a live ledger.

So those rows were not imported, and the decision was stated rather than guessed — it was escalated as a judgement for the owner rather than resolved by whichever rule happened to be easiest to implement.

The general shape: an overlap is not a technical problem with a correct answer. It is a question about which record is authoritative for that period, and that question belongs to a person. What the import must do is make the overlap visible before it runs, rather than silently applying a preference.

Preserve what the source knew#

An import is an opportunity that comes once, and the most common regret is having dropped fields because the target had nowhere to put them.

Our register carried things the live system had never held: who received each delivery, the document number, the rate including tax, the workability reading, and the seven- and twenty-eight-day test results where they had been taken. Those were exactly the fields that turned the imported rows from a volume total into evidence — for the reasons set out in the concrete cube test, a result with nothing to attach it to is a number with no owner.

If the target has no column, add one. Discarding a field at import time is permanent in practice, because nobody re-runs a historical import to recover a column they decided was unimportant.

Set the state honestly#

Imported rows land in some state, and the default is usually wrong.

Ours were marked as received, because the register is the proof of receipt — every row names the officer who took delivery. Left in the default state they would have shown on the way, did it land? for ever, on hundreds of rows, about concrete poured months earlier.

That would not have been a cosmetic problem. A screen full of permanently unanswerable questions is a screen people stop reading, and it would have taken the genuine current items down with it. A check that can never be satisfied is worse than no check — the same trap described in money before material, where a warning that was always on had become wallpaper.

Back up the specific table, and say so#

Before the write, back up what the write touches. Not the whole database as a matter of ceremony — the specific table, so the restore is a real option rather than a theoretical one.

And record, in the change log, that it was done. Somebody looking at this a year from now needs to know the backup exists and where.

The order that works#

1. Parse, and reconcile to a total the source itself claims.
2. Resolve the rows that will not parse, individually, by hand.
3. Identify the overlap with existing data and put the decision to a person.
4. Add the marker field to every row that will be written.
5. Back up the target table.
6. Write, in a transaction.
7. Run it again and confirm it writes nothing.
8. Verify the totals in the live system against the source.

Steps one, three and seven are the ones people skip, and they are the three that decide whether the import is recoverable.

Migrations deserve the same discipline#

Everything above applies to schema migrations as well, with one addition: migrations should be additive and idempotent, and proven so by running them repeatedly against a throwaway copy before they go anywhere near production.

Ours are applied to production ahead of the code that needs them, in that order, always. Code that expects a column which does not exist yet fails immediately and visibly. A column that exists before the code needs it is harmless.

And where a migration cannot be made automatic, it is stated as a manual step in the release notes rather than assumed. An unstated manual step is a production incident with a delay fuse.

The short version#

Tag every row you write so a second run does nothing and a reversal is exact. Reconcile to a total the source itself claims, before writing anything.

Put the overlap in front of a person instead of resolving it by rule. Keep the fields the source knew and your system did not. Set the imported state to what is actually true, not to the default.

And back up the specific table you are touching, so that the way out is something you have rather than something you would have to invent.

A very large number of tests do something subtly different: they state what the code currently does and check that it still does it. Those two things look identical while the code is correct, and they diverge sharply the moment it is not.

The test that held a defect in place#

A concrete case from our own system, and it is the least comfortable thing we found that week.

A payment made in stages was not being recognised as paid, because the instalment path never wrote the field that means this is paid. There is a prompt that should appear on an order once its money has settled — this is paid, close it? — and on staged orders it never appeared.

The prompt had a test. The test passed.

It passed because it was anchored on the same stale field the code was reading. At the time it was written, that field was what the code checked, so the test faithfully described the code. It went on passing happily while the prompt failed to appear on exactly the orders it was built for.

A test that describes the code rather than the rule will defend a defect as loyally as it defends a feature, and it will do it while reporting green.

Why this happens so easily#

Because the code is right there.

When you write a test after the implementation, the implementation is the clearest available description of what the system does, and the path of least resistance is to assert against it. The test then has exactly the same blind spots as the code, because it was derived from it.

The rule, meanwhile, exists in somebody's head, in a requirement written months ago, or in a conversation. Getting it into the test requires going back to it deliberately.

This is not a discipline problem that can be solved by trying harder. It is a consequence of the order in which things are written, and the only reliable counter is to state the rule in the test's own language — in domain terms, with values a person would recognise — rather than in the code's terms.

The check that was wrong about itself#

A second case, and the mechanism is different enough to be worth telling.

We had a defect where an invisible overlay was swallowing clicks across a whole page. The fix was general: an overlay that cannot be seen may not take a click.

To stop it coming back, we wrote an automated check that looked at the relevant code and confirmed the two necessary things sat together.

The check passed. It passed with the bug sitting directly in front of it.

The long comment explaining the fix had been placed between the two things the check needed to compare, which pushed one of them outside the window it was looking at. So the check saw one and not the other, concluded nothing was wrong, and would have gone on concluding that for as long as anybody cared to trust it.

We only found out because we put the bug back on purpose to watch the check go red. It did not. The check now strips comments before it looks, and it was re-tested the same way. The whole episode is in the complaint names the wrong thing.

Watch it fail#

The single most valuable habit in this area takes about a minute.

Break the thing on purpose and confirm that something notices.

A test you have never seen fail is a test you are trusting on its own word. It might be asserting nothing. It might be looking at the wrong object. It might have been silently skipped for a year because a filter changed. All of these are common and none of them is visible in a green result.

Almost nobody does this, which is why so many green suites are green for reasons unrelated to the code being correct.

Anchor on the rule, not the mechanism#

Practically, the difference shows up in what the test asserts against.

Describes the code: asserts that a particular field is empty, that a particular function was called, that a query has a particular shape, that a value is stored in a particular place.

Describes the rule: asserts that after an advance and a balance are recorded, the order is treated as settled — by whatever means the system uses to decide that.

The second survives a refactor. More importantly, the second fails when the refactor is wrong, which is the entire reason the test exists.

The best available anchor is a real case with real values that a person from the business would recognise. Our own money rules are held to the figures from an actual settled order, which means the assertions are checkable by somebody who is not a programmer.

One rule, one implementation, one test#

There is a structural point underneath all of this.

If a rule is implemented in two places, testing one of them tells you nothing about the other. And rules do get implemented twice — we found the same question about whether money had settled being asked in nine separate places, each written by somebody who reasonably assumed the obvious field meant what it looked like it meant. The account is a fact that had no owner.

The remedy is the same one that fixes the underlying defect: one function owns the rule, everything asks it, and the test tests that function. A test suite cannot compensate for a rule that has been copied. It can only ever check the copy it was pointed at.

What a suite should be for#

Not proof of correctness, which it cannot provide.

A suite is a set of statements about what must remain true, written so that a change which breaks one of them is caught by somebody other than a customer. Its value is entirely a function of whether those statements are about the domain or about the implementation.

Which suggests a review question worth asking of any existing suite: pick five tests at random and ask, for each, what rule would a business person recognise here? If the answer is a description of code structure, that test will defend whatever the code does, correct or not.

The short version#

A test written from the implementation inherits the implementation's blind spots and will guard a bug while reporting green.

State the rule in domain terms, with values somebody outside engineering would recognise. Break the thing on purpose and watch the test go red before you trust it. And remember that a test can only check the copy of a rule it was pointed at — which is one more reason a rule should exist only once. The principle behind that is in append-only records and, more directly, in every gap we have written about here.

It is not the dramatic kind. Nothing crashes, nobody escalates, no one writes a report about it. It is the form that has to be filled twice. The number that only one person knows how to look up. The step where somebody re-types what a machine already knew. Every day it costs a few minutes and a small amount of attention, and every day somebody quietly absorbs the cost.

Then the second thing happens, and it is the important one: the workaround becomes the habit. Somebody works out how to get around the problem, teaches it to the next person, and within a year the workaround is simply how the job is done. The gap has not closed. It has been staffed.

Why nobody fixes it#

Ask why it is like that and the answer comes back in a very recognisable shape — that is simply how things work. It is said without resentment, usually by someone competent, and it is nearly always false. It is not a description of reality. It is a description of how long everyone has been living with something.

That sentence is the reason BE Teck exists. People inside BE kept hitting the same walls and kept being told the same thing, and eventually somebody refused to walk around the wall for the tenth time.

Three rules, and the third is the odd one#

BE Teck takes on very few things, because three rules decide everything.

It has to be real#

No demos, no decks, no pilots that quietly die. If a thing cannot survive a full working day in the field, on a bad connection, it is not finished and we do not call it built. The test is never the demo. The test is the worst day.

It has to be big enough to matter#

Small annoyances can wait. The gaps worth taking are the ones that cost people time, money or safety every day, and the ones where being wrong has a real consequence — a payment, a document, a site, a person's month.

It is not about the money#

This is the rule people find hardest to believe, and it is the one that actually shapes the work. BE Teck exists to give something back, not to extract. If the right answer to a problem is to hand a thing over, or give it away, that is what happens. Profit was never the point of forming it.

The third rule is not decoration. It changes what gets built, because it removes the pressure to keep a problem alive so that a product can keep selling the cure.

How to spot one#

If you want to find these gaps in your own work, do not look for complaints. Complaints mean the problem is still visible, and a visible problem usually has someone assigned to it. Look for calm instead:

• A step everybody performs but nobody can justify.
• Knowledge that lives in one person's head and has never been written down.
• A rule that exists only because of a limitation that was removed years ago.
• Something you have personally stopped mentioning because mentioning it never changed anything.

That last one is the strongest signal there is. The moment you stop complaining about something is usually the moment it became permanent.

We close the gaps everyone else learns to live with. Not a tech company. A repair habit that got organised.

Two of the gaps we have found this way are written up in full, and both began as something nobody had thought worth mentioning: a fact that had no owner, where a paid order kept asking to be paid again, and written, and never wired, where the fix already existed and had no button.

If something in your daily work is broken in a way everybody has stopped complaining about, that is exactly what we want to hear about. Write to hello@be-teck.com and describe the wall.