Build it on time. Build it right.

The contract becomes the budget — so a change to the contract shows up here immediately.

The budget is not retyped — it is derived from the head contract and breaks into bands, with every cost code split across labour, material, equipment and subcontractor. A change request that has been approved and signed is written into the contract itself and moves both the scope and the budget in the same motion, rather than as a form somebody has to pass along. That is the difference between a module and a system: a band that turns a colour turns it because something really happened in the contract.

• A budget derived from the contract, not typed beside it
• A cost-code by cost-type matrix — labour, material, equipment, subcontractor
• Change request → approval and signature → a line in the contract → an updated budget
• An overrunning band is flagged, and you see which item it was born in
• Budget transfers with a full audit trail
• Every change to the contract scope appears in the budget at once

Four documents line up on their own. Whatever breaks tolerance stops.

Every subcontractor has a cumulative account: committed, executed, paid, balance. Above it sits the four-way match — requisition, order, goods receipt and invoice all lining up on the same quantity by themselves. An invoice that drifts past the tolerance profile is stopped rather than merely flagged, and whoever approves it anyway has to say why, with their name left on the decision. This is the capability that separates a construction finance system from an accounting package.

• A cumulative account per subcontractor — committed, executed, paid, balance
• A four-way match: requisition, order, goods receipt, invoice
• A tolerance profile per item, not one tolerance for the whole project
• A break above tolerance stops, rather than merely turning a colour
• Approving past tolerance needs a reason, and keeps the approver's name
• Subcontracts and purchase orders on the same commitment

A payment application built from the cumulative account — issued as a document you can submit.

The payment application is not typed: it is built from the cumulative account, and the retention and VAT lines are computed rather than entered by hand. From there it runs a multi-step approval route, and at the end a branded PDF comes out — a document you can submit to the employer, not an internal report. The final account is built from the same source, so it never argues with what was approved along the way.

• A payment application built from the cumulative account
• Retention and VAT computed, not typed
• A multi-step approval route before the application goes out
• A branded PDF — a document for submission, not an internal report
• A final account built from the same source as the applications before it

Three statutory duties no system from abroad has ever heard of.

Israel's statutory payment-terms law sets a due date, and Atlas computes it — it does not remind you to go and check. The payments-due page shows the statutory date and the days remaining on every account, and beside it three real warnings: a withholding-tax exemption certificate that has expired, an invoice above the allocation-number threshold, and an overdue payment with interest accrued. The page comes out as a document you can submit, not as an internal report.

• Statutory payment terms — a statutory due date computed per account
• An expired withholding-tax exemption certificate
• An invoice above the allocation-number threshold
• An overdue payment with interest accrued
• The allocation number is checked before the invoice moves on
• A days-remaining clock, not a reminder in somebody's calendar

The construction inputs index is pulled and calculated on its own.

The construction inputs index series is pulled in, and linkage is calculated on the account itself: base index, operative index, and the difference at the end. The calculation does not live in somebody's spreadsheet off to the side — it is stored on the account, so it can be reproduced two years from now, including which index was in force in which month.

• The construction inputs index series is pulled automatically
• Base index, operative index and difference — on the account itself
• Linkage per the contract terms, account by account
• Every calculation is stored and reproducible years later
• You can see which index was in force in each month

And what the position really is — and where it is heading.

The cost-value report shows cost against the value delivered, with a monthly cash flow and a forecast to completion beside it. CPI, EAC, VAC and TCPI are not dashboard decoration here: each one carries a breakdown of what is generating the overrun. The answer is not that you overran, but in which band, in which item and in which account it was born.

• Cost against the value delivered, not cost against budget
• CPI, EAC, VAC and TCPI — each with its own breakdown
• A monthly cash flow built from the accounts and the commitments
• The overrun broken down to the band, the item and the account it started in
• A forecast to completion that updates with every account that comes in

Four things that normally live in four spreadsheets.

Guarantees, liquidated damages, set-offs and daywork — in the same place, and against the same commitment. The guarantee card shows an expiry approaching before it lapses, a set-off is recorded against the item it was set off from, and daywork is documented as work performed in hours and materials rather than as a line somebody remembers. By the time the final account arrives there is no argument about what was agreed.

• Performance and advance guarantees with a validity register
• An alert on a guarantee whose validity is running down
• Liquidated damages computed from the contract terms
• A set-off recorded against the item it was taken from
• Daywork documented in hours and materials, as work performed

Every question has somebody responsible for it, and a clock that is running.

A question nobody answered is a delay in waiting, and here it does not disappear into an inbox: every enquiry has an owner, a target date and a clock, and an overdue row looks overdue. The drawer holds the whole history of the enquiry — who asked, against which revision, who answered and when — and the correspondence around it too, stamped with who opened it and when. "I sent it to you" and "I never got it" are half the arguments on a site, and here both of them have a date.

• An owner, a target date and a clock on every enquiry
• An overdue enquiry looks overdue instead of sinking in a queue
• Pinned to the revision the question was asked against
• External consultants answer from email, and the answer attaches to the record
• Correspondence stamped with who opened it, who read it and when
• Cost impact flagged and passed through to the budget team

Reviewed, versioned, and handed over at the end as a single register.

A submittal package runs a review with reviewers and target dates, and every status change — approved, returned, rejected, archived — is timestamped and attributed to whoever made it. Every draft is kept, so you can show exactly what was sent the first time and what changed afterwards. The submittals register is what the contract manager hands the client at handover, without reassembling it out of folders.

• A review route — approved, returned, rejected, archived
• Every draft kept, with who changed it and when
• Linked to the specification and drawing set the submittal belongs to
• Reviewer assignment with target dates and a clock
• A submittals register ready to hand to the client

Every defect sits on a point on the drawing. Not "in the corridor, near the door".

The defect is captured on the drawing itself, with a photo, an owner and a target date, and the subcontractor opens the drawing and sees exactly where. A formal non-conformance travels the same route: raised, corrected, verified — and it closes only once somebody went and checked, with a verification photo on close. The sub sees their own list in the field app the moment you save.

• A defect pinned to a coordinate on the drawing, with a photo and an owner
• A separate list per subcontractor, distributed automatically
• A non-conformance closes only once somebody checked and verified
• A verification photo on close, not just a status change
• A handover summary view — what is open, in correction, verified

A claim fails for want of evidence, not for want of justice.

A delay event recorded in the field becomes a claim you can prove: the event timeline is built from the records, the days are counted against the contract terms, and the evidence file assembles itself out of the daily logs, the photographs and the correspondence from those same days. An extension-of-time submission goes out with its annexes attached, rather than as a letter asking the other side to take your word for it.

• A delay event logged when it happens, not when it is remembered
• An event timeline built from records that already exist
• Extension of time computed against the contract terms
• An evidence file that assembles itself from logs, photos and correspondence
• The submission goes out with its annexes attached

Who is on site, and who is even permitted to be.

The workforce register holds operatives, companies, certifications and insurance, and anyone whose certification or insurance has lapsed is marked barred from entry before they are standing at the gate. And from there through to settlement: the gate clock, the timesheet, the site manager's approval — and the gap between what the subcontractor reported and what the gate recorded is shown before you pay, not after. Labour cost is coded to its cost code in the same motion.

• A register of operatives, companies, certifications and insurance
• A lapsed certification or insurance marks somebody barred from entry
• A gate clock, a timesheet and an approval in the field
• The gap between the sub's report and the gate record — before payment
• Attendance derived from the daily log, not keyed in twice
• Labour cost coded to its cost code

Build the form once — and fill it in a thousand times.

The form builder produces the checklists people actually fill in on site, and they are signed and timestamped, zone by zone. The certificate register warns about a validity running out before it runs out, and the equipment card holds the test, the insurance, the inspector's report and the sign-off — one of them in red is the reason a crane does not go up this morning. A corrective action opened by an inspection stays open until somebody has closed it.

• A builder for forms and checklists — built once
• Daily inspections signed and timestamped, zone by zone
• A certificate register with validity alerts
• An equipment card — test, insurance, inspector's report, sign-off
• Corrective actions tracked through to close
• All of it from the field app, linked to the zone and the crew

The three things everybody looks for right after something happened.

A work permit opens with the conditions that were approved and with a signature, a pre-task plan attaches to the task itself, and a hazard reported from a phone closes against whoever owns it. And a safety incident is recorded in the field — type, place, witnesses and photos — and comes out as a branded report with every annex: a document you can submit, not an internal report somebody has to retype.

• A work permit with the approved conditions and a signature
• A pre-task plan attached to its own task
• A hazard reported from a phone, closed against an owner
• A safety incident logged in the field — type, place, witnesses, photos
• A branded incident report with annexes — a document for submission

A handover round that ends in a signed protocol — from the tablet.

The buyer's comments drop onto the apartment plan, they sign for what they saw themselves, and a signed protocol comes out; the comments become defects with an owner and a target date rather than a list on a sheet of paper. After that, tenant variations, service calls and the defects-liability period all sit in the same file. Authority submissions run with statuses, and every completion demand opens as a task with an owner — no waiting on the municipality with nobody accountable — through to the occupancy approval. And the handover package assembles itself out of documents that were already collected.

• A handover round from the tablet, with comments on the apartment plan
• The buyer signs for what they saw, and a signed protocol comes out
• A comment becomes a defect with an owner and a target date
• Tenant variations, service calls and the defects-liability period in one file
• Authority submissions through to Form 4 and the occupancy approval
• A link that opens with no login, for whoever needs to see it from outside

The right folder, the right version, and the right person.

Every contract, specification, revision and inspection record in one tree — versioned, permissioned by role, searchable. Each document hangs on the same zone tree the records hang on, so a question about one apartment returns its documents too. It is linked to the enquiry or submittal it belongs to, the handover package is built out of it, and nothing lives on somebody's laptop any more.

• One folder tree, with a version history per file
• Role-based permissions — who sees what
• Every document hangs on the project's zone tree
• Linked to the enquiry, submittal and revision it belongs to
• Upload and browse from a phone, from the field too
• Share links with an expiry

A team that is always on shift — and waiting for you to tell it to start.

Three AI workers arrive paused: they don't start working because you installed them, and you switch them on one at a time. The quantity surveyor proposes measurements on the drawing and never writes to the bill of quantities itself — only your click creates a line. The meeting secretary records what was decided and who owns it. The control analyst issues a weekly brief on this project's bands, accounts and deadlines, and every figure in it was pulled from a record you can open. Atlas sends nothing and changes nothing without your approval.

• Three workers that arrive paused — switched on one at a time
• Who switched it on and when is recorded on the activation itself
• A quantity surveyor that proposes measurements on the drawing
• Only your click writes a line to the bill of quantities
• A meeting secretary — what was decided, and who owns it
• A control analyst — a weekly brief, with a record behind every figure

Who approves, from what amount, and what happens when nobody answers.

Approval workflows run in the background with an approver hierarchy, and a route that stops on waiting-above-the-threshold is configuration rather than code — you change who approves, from what amount, and what happens when there is no answer, without a developer. And underneath it: the separation between organisations lives in the database itself and not only in the application, and every action is written to an audit log from which not even an organisation admin can delete a row.

• Six approval workflows running in the background
• An approver hierarchy by amount and by type
• Changing who approves and when — configuration, not code
• Data separation between organisations in the database itself
• An audit log not even an organisation admin can delete a row from

The system — in your brand.

The sidebar, the sign-in screen and the PDF header all switch together to your brand palette, and your client's client never sees Atlas anywhere. Underneath, it connects to what already works for you — accounting, mail, calendar and chat — through an API with keys and scoped permissions, and a row that failed to match is not forced through but waits for somebody to look at it. All of it in Hebrew and English, with full RTL rather than translated text in a left-to-right layout.

• One brand palette across the sidebar, the sign-in screen and the PDF header
• Your client's client never sees Atlas
• Connects to accounting, mail, calendar and chat
• A public API with keys and scoped permissions
• A row that failed to match waits for review instead of being forced through
• Hebrew and English with full RTL — the direction flips, not just the text