Jobs and sites
A register of jobs with their client, their status and their dates, and a job file behind each one. Opening a job gives you its documents, its labour and its commercial position without leaving the record.
Construction finance and project control - projects, subcontractors, valuations, supplier statements, invoices, variations and retentions, with the paperwork attached to the money it belongs to.
Available now. SiteLedger is deployed and reachable, and it is still actively developed. We would rather show you what is in the application today than have you infer it from this page, and where each of our products stands is stated plainly.
Every register in SiteLedger hangs off a job, so the paperwork stays with the work it belongs to instead of in a folder named after a month.
A register of jobs with their client, their status and their dates, and a job file behind each one. Opening a job gives you its documents, its labour and its commercial position without leaving the record.
A CRM register of client companies with contacts, addresses and the jobs attached to each. A client opens to their own record, and the jobs on it are the jobs you can see.
Existing works folders are taken in through a review queue rather than imported blind. Each candidate is shown with what was read from it, and a person decides: resolve it to a job, treat it as a duplicate, or send it back to the queue. Nothing is filed because a filename looked right.
Files are filed on the job and reachable from it. Which jobs a person can open decides which documents they can open, and asking for a job outside that slice is refused rather than quietly answered with an empty page.
The hours a job actually took, kept so they can still be read back years later against the codes they were booked to.
Staff records belong to the company that employs them, and are readable and writable only inside it. Someone else's worker is not a page you can reach by knowing an address.
Hours are allocated to a job and a cost code, and carry the kind of time they were. The kind is stored as a stable code and never as its label, so renaming "Overtime" in your settings does not restate what a job cost three years ago.
Supplier paperwork read carefully, and the company's own rates held where they cannot be changed by everybody.
A supplier statement is taken in and read line by line: invoice numbers, ticket references and amounts, with what could not be read reported as unread rather than dropped. Lines are confirmed, corrected or queried by a person, and the evidence behind each one stays attached to it.
VAT, CIS and default markup are company-wide values, so they are held to the settings publication role rather than offered to anyone who finds the screen. A rate that will not parse is refused rather than stored, because a cleared box that saved as zero would quietly reprice everything quoted after it.
A register of the obligations a company carries, each opening to its own record, with an export for the ones you need outside the system.
The register, the record and the export are all scoped to the company asking. An export asked for against another company's id is refused outright, not filtered quietly to nothing.
The parts nobody asks for in a demonstration and everybody depends on.
Every register and every record is scoped to the company asking, and this is checked by trying: a signed-in user of one company asking for another company's obligation, job, worker or document by its address gets the same answer as for an address that names nothing at all. Telling somebody they may not see a record confirms the record exists.
Reading a screen and being allowed to change what is on it are separate questions. A company-wide value is held to the role that publishes settings, and the refusal happens on the server, not by leaving a button off a page.
Corrections, approvals and withdrawals are kept as a history rather than as a current value with the past written over it. A withdrawn approval still shows that it happened, because removing the evidence of a decision is not the same as reversing it.
The database SiteLedger runs on can be rebuilt from nothing by its own migrations, and what that produces is checked against the schema the application is generated from. A system that cannot recreate its own structure is a system nobody can safely move.
The quickest way to judge SiteLedger is against work you recognise.