For construction accounts payable
Upload a hauling invoice and the quarry, scale and load tickets that came with it. Every ticket is read into structured fields, checked against the invoice line by line, and compared against every ticket your company has ever processed. Then you review the handful that do not agree — not the other four hundred.
No card, no integration, no data migration. Send one invoice and its ticket packet, and see the result before you decide anything.
Exceptions to review
8 of 487 tickets
Ticket 88421
Already invoiced on invoice 4471, dated Mar 12
$412.50
Ticket 88503
Net tonnage 24.10 t on the ticket, 25.50 t on the invoice line
$19.60
Ticket 88617
Rate $14.50 per ton against a contract rate of $13.75
$168.75
Ticket 88744
Gross minus tare does not equal the stated net
$96.25
479 tickets verified, nothing to do
$2,417.30 in question
Example reconciliation
One hauling invoice from an aggregate broker, submitted the way it arrived: a PDF of the invoice and a stack of photographed and scanned tickets. This is the whole result.
The eight exceptions were a ticket already invoiced two weeks earlier, three tonnage disagreements, two rates above the agreement on file, one ticket whose gross minus tare did not equal its stated net, and one ticket too faint to read with confidence.
One packet, scanned and photographed, submitted as it arrived.
Matched to an invoice line, arithmetic checked, rate confirmed, no prior claim found.
Each one arrives with the reason stated and the ticket image beside it.
Recomputed from the tickets up, not taken from the invoice footer.
The portion of the invoice the evidence does not yet settle. The rest is ready to approve.
What it catches
A 500-ticket invoice is a full day of keying, matching and adding up. The duplicate check at the end of that day is the one that gets skipped — and it is the one that costs the most.
Every ticket your company processes joins a permanent registry. Each new ticket is checked against all of it — not just against the other tickets on the same invoice, and not just against last month. A ticket resubmitted a quarter later on a different invoice is still caught.
Gross minus tare must equal net. Net tonnage must match the invoice line. The rate must match the agreement on file. The extension must match both. Every ticket, every line, every time — not the ten a person had time for.
Nothing is flagged as "suspicious". A flagged ticket says what disagrees and by how much: tonnage 24.10 against 25.50, rate $14.50 against a contract rate of $13.75, ticket 88421 already invoiced on March 12. You can act on that in seconds.
Each exception opens with the ticket image next to the extracted fields, so the person reviewing it can confirm the finding against the paper without leaving the screen or digging through a box.
Who uploaded it, what was read from it, what a person changed, who approved it and when payment was recorded — all kept as an append-only history. When a subcontractor disputes a deduction six months later, the answer is one search away.
Submitted on another invoice, approved in the system, marked paid by a person, and matched against your payment register are four different claims with four different weights. Approval alone never becomes "already paid".
How it works
The first five run on their own. The sixth is the only one that requires judgement, and it is the only one you spend time on.
Step 1
Drop the invoice and the ticket packet in together — phone photographs, flatbed scans, or a single 1,200-page PDF. Nothing has to be sorted, renamed or straightened first.
Step 2
Each ticket becomes structured fields: ticket number, date, quarry, hauler, truck, material, gross, tare and net. Anything read with low confidence is marked for a person rather than assumed.
Step 3
Fixed rules run against every ticket. Gross minus tare must equal net. Dates must be plausible for the haul. Weights must be within the tolerance your scales actually produce.
Step 4
Every ticket is compared against your organization’s entire ticket registry — every ticket, from every invoice, from every hauler you have ever processed. This is the step a person cannot do by hand.
Step 5
Tickets are matched to invoice lines, rates are resolved from your agreements and purchase orders, and the invoice total is recomputed from the tickets up rather than trusted from the footer.
Step 6
You see only what disagrees, with the reason in plain language and the ticket image beside it. Resolve, correct or reject each one, then approve the invoice with a number you can defend.
No figure in this platform is produced by a guess. Every total, every difference and every duplicate finding is computed by rules that can be read, tested and explained to an auditor.
Who it is for
If your invoices arrive with a stack of scale tickets behind them, this was built for your desk.
You subcontract hauling on every job and receive broker invoices with hundreds of tickets attached. The tickets arrive in whatever condition the driver’s cab left them in, and the person checking them has other work.
Aggregate, base and fill move by the thousand tons across long schedules and several pits. A ton of drift on a single ticket is invisible; the same drift across a season of tickets is a line item nobody budgeted for.
Hot mix is priced by the ton and delivered against tight windows and multiple mix designs. A rate applied from the wrong agreement, or a ticket billed twice across two pay applications, is easy to miss and expensive to keep.
You are accountable for what gets paid and for being able to show why. You need the arithmetic checked, the duplicates found, and a record that survives an audit or a dispute — without adding a headcount to do it.
Security and access
A hauling ledger is a map of who you work with and what you pay them. It is treated as such.
Duplicate checking runs inside your organization and nowhere else. Your tickets are never pooled with another company’s, and no other customer’s haul rates, quarries or subcontractors are ever visible to you — or yours to them.
Every database query in the platform is required to carry the organization it belongs to; a query written without one does not run. A request for another company’s record is answered the same way as a request for a record that does not exist.
Owner, administrator, AP specialist, approver and viewer are separate roles with separate powers. Approving an invoice and recording a payment are distinct permissions, and both are re-checked against your current membership at the moment of the action rather than from a cached credential.
Every uploaded ticket and invoice is encrypted in transit and at rest and kept as the underlying evidence for its findings. Images are served through short-lived links, and downloading an original writes an audit record naming who took it.
Questions
Anything not answered here, write to support@truconcile.com and a person will reply.
The invoice and the tickets that came with it. A PDF, a folder of scans, phone photographs, or all three mixed together. Tickets do not need to be sorted, deskewed, renamed or in any particular order.
It becomes an exception rather than a guess. You see the image next to the fields that were read, fill in what is missing, and the correction is recorded with your name against it. A ticket is never quietly assigned a tonnage nobody can see on the paper.
From your own records, and the platform is careful about the difference. A ticket that appeared on an earlier invoice was submitted. An invoice approved here was approved. A payment recorded by a person, or matched against a payment register you import, was paid. Approval on its own is never reported as payment.
No. Nothing is installed, nothing connects to your ledger, and no data is migrated. You upload invoices and tickets and get back a reconciliation. If you later want approved invoices to flow into your accounting system, that is a separate conversation, not a prerequisite.
Packets of a thousand tickets and PDFs of over a thousand pages are within the normal working range. A large packet takes longer to process than a small one; you can leave the page and come back to the finished result.
Minutes for a typical packet rather than a working day. The tickets are processed in parallel and reconciliation runs once every one of them has finished, so the result you review is always computed from the complete packet — never from a partial one.
Yes. Exceptions can be assigned, annotated and resolved by different people, and each action is recorded against the person who took it. Approving an invoice and recording a payment are separate permissions, so an approver need not be given upload or correction rights.
One complete invoice with its full ticket packet, processed end to end, with every exception and every reason shown. No card, and no obligation to continue.
Pick the worst packet on your desk — the thickest one, the one with the tickets that came out of a glovebox. You will have the exceptions, with reasons, before you would have finished keying the first fifty.
One invoice, one full ticket packet, every exception shown. No card required.
Would rather be walked through it? Schedule a demo.