Budget and actuals by work item
The budget goes down to the work item; actuals coming from site match against the same item. Which work item is over budget is visible before the project ends, in time to intervene.
Pan Enterprise Solutions, the software arm of Pan Innovation House · based in Gaziantep, Türkiye, with a London office
We do not replace your accounting software or your project planning tools. We bring quantity take-offs and progress payments, subcontractor contracts and progress, site timesheets, material and warehouse movements and true cost per work item together in a single layer between office and site. The source code we write is handed over to you as defined in the contract.
Asking about price? We listen to the scope in a short call and share the budget frame and timeline in writing. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We work on site for plants in and around Gaziantep; elsewhere in Türkiye and abroad, discovery starts by video call and a visit is planned if needed. Our London office is at Unit 6 Cranford Way, Hornsey, London N8 9DG.
In contracting, profit or loss is made on site every day, not at project close. Yet in most firms the picture the office sees forms at month end, from accounting records; the delay in between turns a correctable deviation into an uncorrectable one.
Design and planning run on mature tools in this sector, and accounting is well established. The gap opens in the site management that sits between them, above all around subcontractors and progress payments.
| Layer | Software in use today | The gap it leaves |
|---|---|---|
| Design and modelling | AutoCAD, Revit and similar building information modelling tools | They are established tools on the design and model side and stay in place; they are also strong at producing quantities. Their limit is the link to the site: comparing model quantities with actuals is not these tools' job. In most firms the model is right and the site record is missing; because the comparison cannot be made, the accuracy the model provides goes unused in practice. |
| Quantities, estimating and progress payments | Oska and similar estimating and progress-payment software, Excel templates | They are widely used, especially on public works, and are built around the pay-item logic; they do their job on the client progress payment side. The gap is on the subcontractor side: subcontractor progress, deduction, advance and retention tracking, and the true cost on site, usually run outside these tools in separate sheets. And the firm's profit or loss is made precisely in that gap. |
| Project planning | Primavera P6, Microsoft Project | Mature tools for work programming and resource planning. The problem is not the tool but what feeds it: because actual progress does not flow regularly from site, the programme soon stops reflecting reality. A work programme that is not updated is not merely useless, it is misleading; decisions are made against a schedule that has in fact been overrun. |
| Accounting and finance | Logo, Mikro, Netsis and similar systems | Necessary on the financial side, and they stay in place; they carry progress payments, invoices and accounts. They show cost by account, not by work item. That is why accounting records eventually say whether a project made money, but never say on which work item it was lost. |
| Public procurement and regulatory interfaces | EKAP and related public systems, building inspection processes | They are mandatory processes on the tender and contract side and have their own order. Relating the data in these systems to the firm's own cost and progress tracking is a separate job, and in most firms it is never done; the pay-item structure of the contract and the tracking of work on site run in two different languages. |
| Site communication and records | Messaging groups, photo archives, paper minutes | The sector's most critical records are created here and stored in no system: variation instructions, handover minutes, work photographs and the site manager's notes. In a dispute, months-old messages are trawled for evidence. This is the intervention point that removes the most risk at the lowest cost. |
Product names are compiled from vendors' public pages (September 2026); PAN is not affiliated with them. The "gap" column summarises situations we commonly meet in discovery and is not a statement about any specific product.
Our solution is not a rival to your planning and accounting tools. It makes the reality forming on site measurable and keeps the picture the office sees current; that way a deviation shows when it occurs, not at month end.
The budget goes down to the work item; actuals coming from site match against the same item. Which work item is over budget is visible before the project ends, in time to intervene.
Contracts, unit prices, scope of work, advances, deductions and retentions run in a single record. Progress payments are calculated from that record; the reconciliation argument gives way to documents.
Work progress is recorded on site, on a phone and with photographs attached. Records can be taken offline and sync when a connection returns; poor coverage on site does not stop the work.
Material entering and leaving the site warehouse is recorded; consumption is linked to work items. Loss and over-ordering show without waiting for a count.
Own labour and subcontractor labour are tracked separately; man-day cost is allocated to work items. Labour stops being an item written down by guesswork.
Minutes, photographs, site instructions and handover records are stored with date and location. In a dispute, the evidence sought sits in a corporate archive, not in messaging history.
Not every firm needs all of them. On a single site, subcontractor and progress payment tracking may be enough, while multi-site operations bring the comparative dashboard to the fore.
Budget by work item, actual quantities, and client and subcontractor progress payments run on the same ground.
See the module → ERPContract scope, unit prices, advance, deduction and retention tracking; putting out-of-scope work requests on record.
See the module → MESPhotographic progress records from site, a mobile interface that works offline, matching against work items.
See the module → WMSWarehouse entries and issues, linking consumption to work items, transfers between sites and critical material alerts.
See the module → ERPSeparate timesheets for own and subcontractor labour, allocating man-day cost to work items, producing the file that goes to payroll.
See the module → QMSSite access control, training and document validity, near-miss and incident records, keeping the file requested at inspections ready.
See the module → BIProgress, cost deviation and cash needs by site; seeing early which site is falling behind.
See the module → APIInvoice, account and cost matching with Logo, Mikro and Netsis; feeding actual progress into work programme tools.
See the module →Your design and planning tools and your accounting software stay in place. The layer we build collects the reality on site and produces the data those tools expect.
Our integration approach →We discuss your business structure, your number of sites, your subcontracting model and your current tools. We identify the point that hurts most together and draw a realistic frame; at this stage understanding, not selling, comes first. The call carries no obligation. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We walk at least one site in person. We see how progress is reported, how the warehouse is kept and how timesheets are taken. Site conditions shape the interface design directly; a screen used in gloves and under the sun cannot be designed like an office screen.
We decide which module to build first; subcontractor and progress payment tracking, or site progress recording, usually delivers the highest return. Scope, timeline and deliverables are put in writing.
The system is developed and run in parallel with the existing routine on a single site. Progress payment results are compared with those prepared by hand; every diverging item is examined.
Other sites and modules are added in turn and integrations are switched on. Users are trained, and the documentation and source code are handed over as defined in the contract. Maintenance and support run under a separate agreement.
On site the internet is weak, hands are full and the screen sits in sunlight. We build the interfaces for that reality; a field app that does not work offline is abandoned in its first week.
Your work programme tool stays in place. We collect the actuals coming from site and feed them into it; we do not try to take over the planning job.
The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences. We leave behind no structure that cuts off your access when the project ends.
In this sector the most expensive arguments break out at the reconciliation table. We build the system so that the record and the photograph behind every figure can be shown.
We do not change everything at once. We start on one site and expand as the gains show; progressing while the work keeps flowing is essential.
Documentation and a handover package are part of the job. If another team takes over tomorrow, we deliver in a state they can take over.
If your estimating and progress-payment software does its job on pay items and quantities, it should stay. The gap is usually in three places: subcontractor contract and deduction tracking, documenting the actuals coming from site, and true cost by work item. If your current tool covers these, we will not propose a new system, and we will say so openly.
The field app is built to work offline; records are held on the phone and sync when a connection returns. Photographs are queued the same way. This is the sector's most decisive design constraint; an app that assumes connectivity will not be used on site.
We design set-ups that expect no software use from the subcontractor. Progress and timesheet records are taken by your own site manager; the subcontractor only receives a signed minute or a progress payment statement. Where a subcontractor can use it, a simple approval screen can be added, but that is not a requirement.
Yes, and that is where the real gain lies. When sites are tracked with the same budget and work-item structure they become comparable; which site is falling behind and where cash needs concentrate shows early. Permissions are separated by site; each manager sees only their own site.
Tender and contract processes run through the public systems and we do not change them. The layer we build keeps the quantity, progress payment and document data those processes require in order on the firm's side. Interpreting regulation and assessing technical specifications remains your domain and your consultant's.
Quantity lists from your modelling tool can be matched against budget items. But a one-to-one match between model and site does not happen by itself on most projects; building that mapping is a separate piece of work and is written into the scope explicitly. Promising a fully automatic link would not be realistic.
The timeline depends on scope and is given in writing after discovery. Our approach is to get a working system live on a single site quickly and grow it from there. That way feedback arrives early and the return on the investment shows early.
A working system, plus the source code we wrote, the database and handover documentation as defined in the contract (third-party and open-source components remain under their own licences). User training and initial support are part of the scope. Maintenance and development then run under a separate agreement; you are not obliged to sign one, and you can maintain the system with your own team.
The number of sites and subcontractors, the complexity of your progress payment and contract structure, connectivity on site, the need to match planning and modelling tools, and the ERP connection. We discuss a budget range in the first call; the exact scope, timeline and price are put in writing after discovery.
One person each from site management and accounting, a sample contract, quantities and progress payment file, a subcontractor list, and access to one site to be chosen for the pilot.
During discovery we choose the measures that suit you, such as the time it takes to prepare a progress payment, differences that surface at reconciliation, or the point at which cost per work item becomes visible. We first measure where you are today and agree the target from there; results are not guaranteed.
A progress payment (hakediş) is prepared by multiplying the quantities of work done in the period by the unit prices in the contract, then deducting previous payments, advance offsets and other deductions. For an accurate progress payment, the work done on site must be documented and matched to the work item. In the layer we build, the contract, unit prices, advances, deductions and guarantees sit in a single record, and both the client's and the subcontractor's progress payments are calculated from it.
A quantity take-off calculates, unit by unit, the length, area, volume or count of each work item in the project from the project drawings and site measurements. Estimated quantities set the budget; actual quantities set the progress payment and the cost. We match the quantity lists produced by your modelling tool to budget items, and compare progress reported from site against the same items.
We would like to visit one of your sites and see how progress, subcontractor payments and cost are tracked today; then we decide with you where to start.