Project Margin Before Month-End: Getting Site Data to Finance Within 24 Hours

There is one number that tells you immediately how a contractor's reporting system is built: how many days after month-end management knows the actual margin per project. For most mid-sized and large contractors that number is somewhere between 45 and 60. By then the project has advanced another fifth, crews have moved to a different site, plant is somewhere else entirely, and every decision taken in the meantime was taken blind.

What rarely gets noticed is that the data needed to fix this already exists. It is collected every day, on every site, and in Serbia it is collected by law. The problem is that it ends up inside a signed PDF - and a PDF does not add up.

The data already exists, it is just locked inside a document

The Serbian regulation governing the site inspection book, the site diary and the measurement book (Official Gazette RS, No. 96/2023) requires these documents to be kept electronically, in PDF format, on a digital platform, with daily confirmation by electronic signature from both the responsible contractor and the supervising engineer. For works registered from 1 January 2024 onward this is an obligation, not a recommendation.

Look at what the regulation requires to be recorded every single day: weather conditions, headcount, plant on site, types and quantities of materials, quality checks, samples taken, deficiencies found in the documentation, and unforeseen circumstances requiring a change to the technical solution. The measurement book adds the exact quantities of work actually executed, per bill-of-quantities line item, and it explicitly serves as the evidence base for valuation and payment.

That is, almost field for field, exactly the dataset needed to calculate margin per line item. People, hours, machines, materials, executed quantities, delays. All of it is already being written down. It is simply written in a format designed to be signed and archived, not to be summed.

Which is why the first step is not buying software. The first step is deciding that the same entry, which is being made anyway, gets preserved as structured data and not only as a document.

Coding structure before software

The most expensive mistake in these projects is selecting a tool first and only then working out how costs attach to work. The order is reversed, and the first step is done in a spreadsheet.

What you need is a single identifier valid everywhere: in the main contracting entity, in fabrication, in transport, in the warehouse and in accounting. Five levels are usually enough:

• project - the contract with the client;
• structure or section - a physical unit valued separately;
• bill-of-quantities item - the same code that appears in the contract and in the measurement book;
• cost type - labour, material, plant, subcontractor, indirect;
• resource - the specific worker, machine or stock item.

Three rules around this are worth more than any feature list. The code does not change during the life of the project, not even when a variation order arrives - a variation gets a new line item, not new logic. The code is identical across every legal entity in the group, regardless of whose payroll paid for it. And every document created must physically carry it: work order, delivery note, vehicle log, timesheet, supplier invoice. Costs without a code get allocated later by estimation, and estimation is precisely what you were trying to eliminate.

Get this right and the choice of tool becomes relatively unimportant. Get it wrong and the most expensive system on the market will still produce the wrong number.

The minimum field set captured on site

This is where these projects usually break. Not because people refuse to enter data, but because they are asked for too much of it.

The working rule: an entry that takes more than three minutes on a phone will not get done. Not consistently, not after twelve hours on the line. So the field set has to be short and closed - selection from a list, not typing:

• date and line item code;
• quantity executed and unit of measure;
• workers: who, how many hours, which trade;
• plant: which machine, engine hours or kilometres, and idle hours recorded separately;
• material: item, quantity and origin - warehouse, supplier, or internal transfer from another group entity;
• subcontractor, if any, and their quantity;
• delay: a coded reason, not free text - weather, documentation, material, power, supervision, plant, labour;
• a photograph as evidence of the state of works.

Two details decide the outcome. First, the app has to work without signal and sync later, because pipeline routes generally have no coverage, and "we will enter it in the evening from the office" means you will be collecting recollections rather than data.

Second, delays are the most valuable data point and the one least often captured. Without a coded delay reason you have no basis for an extension of time claim and no basis for a compensation claim, and that is exactly where the money that is somebody else's responsibility gets lost. Free text in the diary does not help here: five different phrasings of the same delay cannot be added together.

Four numbers management looks at on Monday

The goal is not a dashboard with twenty charts. The goal is a handful of numbers that have an owner and a consequence.

Productivity factor per line item. Earned (budgeted) hours divided by hours actually spent. Below 1 means the item is being executed at a higher cost than it was priced. Calculated per line item rather than per project, a deviation on pipeline welding becomes visible while it is confined to one section, not after it has been repeated on three.

Material consumption variance against the norm. Same rule, same granularity. A systematic variance on one item is almost always either a wrong norm, a wrong estimate, or a loss nobody is reporting, and all three call for a different response.

Plant utilisation. Productive engine hours against available hours, idle hours, and an internal machine-hour rate posted automatically to the project instead of being negotiated after the fact. A company with its own fleet is effectively running a small rental business, and rental businesses are measured by utilisation.

Earned against billed. Percentage of completion under revenue recognition against interim payment applications issued. A gap in one direction is unbilled work you are financing out of your own working capital; in the other direction it is revenue you have recognised and still have to execute.

There is a fifth number most contractors do not measure at all: the rework percentage. A review of studies by the Navigant Construction Forum puts the median direct cost of rework at 4.03% of contract value, with a realistic range of 4.03% to 6.05%; once indirect costs are included the range runs from 7.25% to 10.89%, with a median of 9.07%. The Construction Industry Institute's earlier research report (RR 153-11) puts it at 4.4%. If your records cannot answer how much you spent last year on work done twice, that cost has not disappeared. It has simply been booked as something else.

What not measuring actually costs

Research conducted by PlanGrid and FMI across 600 professionals found that roughly 35% of working time goes to non-productive activity, more than 14 hours per person per week. Of that, 5.5 hours go to searching for project information, 5 hours to resolving disagreements between parties, and 4 hours to dealing with mistakes and rework. The estimated annual cost at industry level was 177 billion dollars.

A later Autodesk and FMI study, across more than 3,900 professionals, estimated that bad data - inaccurate, incomplete, inaccessible, inconsistent or untimely - cost global construction around 1.85 trillion dollars in a single year, of which 88.69 billion was rework caused by decisions made on the basis of wrong data. In the same study, only 12% of respondents consistently used project data when making decisions.

These are global figures, largely drawn from projects far bigger than the regional average. But the structure of the loss does not change with scale: most of it is not caused by poor execution. It is caused by information arriving late.

An implementation sequence that does not stop the business

A system that delivers value only once it is entirely finished tends never to be finished. So every phase has to be usable on its own.

Phase 0, two to four weeks. Coding structure and cost breakdown, tested against one project already under way. No software. If bill-of-quantities items cannot be mapped cleanly onto cost codes, you find that out here, and it costs a week rather than a year.

Phase 1, six to ten weeks. Mobile capture on one pilot project with one crew. The same entry produces both the basis for the site diary and a structured record. The success criterion is not "the app works" but that the site manager stops keeping a parallel notebook.

Phase 2. Integration with the existing accounting system through an API - work orders, supplier invoices, stock issues - instead of a migration that halts operations. This is also where you handle what is coming regardless: mandatory electronic delivery notes in business-to-business trade in Serbia start on 1 October 2027, and internal movements of material between your own entities, warehouses and sites are exactly the flow that will have to become an electronic document.

Phase 3. A weekly margin and productivity-factor report per line item. Only now, because only now is the underlying data reliable enough to decide on.

Phase 4. Plant and telematics, subcontractors, material and weld traceability.

Three mistakes that kill this kind of project

Everything at once. Replacing the entire system in one move, across all projects, with historical migration included. That project runs eighteen months, spends its budget on migration, and delivers no report in the meantime.

Double entry. If the site still writes on paper and somebody in the office retypes it, you have not digitised a process, you have added a job. The entry has to originate where the work originates, once and only once.

Measurement without consequence. A report with no owner, one that nobody opens at the Monday morning meeting, stops being filled in within two months. Each of the five numbers needs a name next to it and a question that gets asked when it moves.

Finally, "real time" does not mean a dashboard. It means the person who can correct a deviation hears about it while it can still be corrected. A deviation spotted on Tuesday costs one day of work. The same deviation spotted after the payment application has been certified costs three sections and one difficult conversation with the client.

If you want this running in your own company

APPARO builds exactly this kind of system to order: the layer between the site and finance that no off-the-shelf ERP covers. Coding structure and cost breakdown, mobile capture that works without signal, API integration with your existing accounting system, and a weekly margin and productivity-factor report per line item.

We do not start with software. We start with one of your live projects: we work through the bill of quantities, the cost breakdown and the way valuations and payment applications are handled today, then tell you what can realistically be measured as early as next month and what needs a bigger intervention. That conversation is useful to you even if you order nothing afterwards.

If you want to see what this would look like on a specific project, write to office@apparo.rs or book an intro call at apparo.rs/en/start-project.