What this project is about
Plant-hire invoices can be difficult to review because the invoice, agreed rate and recorded hire dates are held in different places. Ajarvo Hire Audit is an early service prototype that compares those records and identifies lines worth checking. The deliverable is a findings register with supporting calculations and an HTML summary, rather than an automatic assertion that a supplier has overcharged.
The work combines a small Python batch checker with a browser tool for reviewing one invoice line. It sits within a private venture workspace. This public case study describes the high-level functionality and its limits only: source code, internal operating material and customer information are not published here. There is no verified evidence of customer adoption, recovered money or a completed enterprise SaaS platform.
How it works
- Invoice + agreed rates
- Check amounts and dates
- Evidence-linked findings
Compare invoice data with supporting records
The batch checker accepts invoice and agreement CSVs and produces findings for rate differences, billing outside recorded hire dates, possible duplicate lines, arithmetic differences and missing agreements. The output links each finding to the records needed to review it. Missing evidence remains visible rather than being treated as proof that a charge is invalid. Python's standard library keeps the local tool's setup requirements modest.
Offer a private single-line calculation
The browser checker compares paired values entered by the user: agreed and invoiced rates, quantity and line amount, hire start and invoice start, or off-hire and invoice end. Calculations happen locally in the browser without uploading the entered figures. Results distinguish differences that need review from matching values or insufficient information, and the user can copy the summary or clear the form.
Make the result reviewable
The project includes fictional sample records, a findings CSV and an HTML report that explain the output format before real documents are involved. Quantified arithmetic is separated from matters requiring contract interpretation. The broader interface explains that minimum hire periods, collection arrangements, credits, tax treatment and later agreements can change what a flagged difference means. The checker supplies evidence for a decision; it does not make a supplier claim.
The important design choices
Keep the initial product boundary narrow
Implement focused comparisons and reviewable reports rather than presenting a complete procurement or accounting system.
The trade-offA limited workflow is easier to inspect and explain, but assembling the source records and resolving contractual ambiguity still requires human work. It cannot promise automated recovery of money.
Calculate one-line checks in the browser
Let the user inspect a single line without sending its figures to an application server.
The trade-offThis limits data transfer for the quick check, but it does not create saved cases, shared review history or a full batch-processing workflow. Those would require additional product and data-handling design.
An invoice period extends beyond a recorded off-hire date
A reviewer has an invoice line and a supporting off-hire record whose dates do not appear to agree.
- The reviewer enters the invoice end date and recorded off-hire date into the browser checker.
- The tool identifies the date gap and marks it for review, preserving the distinction between a calculated difference and a confirmed billing error.
- The reviewer checks collection terms, minimum periods and any later agreement before deciding whether to raise a question.
What this showsThe calculation helps focus a human review. It does not establish an amount recoverable from the supplier or authorise contact with them.
Illustrative example, not a production incident.
How it was tested—and what it shows
The checks
The private project contains a regression test that checks the sample data produces the expected categories of findings. The browser implementation includes input validation and separate handling for matching values, exceptions and incomplete comparisons. The available material supports a functioning prototype with illustrative outputs; it does not constitute independent financial validation, broad contract coverage or testing against a representative customer invoice population.
What to take from the results
The useful engineering result is a traceable path from source records to understandable exceptions, with a local browser calculation for quick checks. The largest uncertainty is the real review workflow: source completeness and contractual terms determine whether a difference warrants action. The prototype prepares evidence for human review; it has not established confirmed overcharges, measured savings or commercial traction.
What to keep in mind
- Contracts, billing conventions and missing records can change the interpretation of a finding. Human review is required.
- This is an early prototype, not a full SaaS product. No verified customers, recovered savings or paid-pilot results are claimed.
- The repository and internal business material remain private.
Technical notes & source
Built with
Python 3.11 · CSV · JavaScript · HTML/CSS
Terms used in this project
- Off-hire date
- The recorded date when hired equipment is no longer required, subject to the agreement’s terms.
Private repository. This page shares a summary, not private source code or raw research files.