From the site log sheet to the GST invoice and the Tally voucher
The client runs a heavy earthmoving and lifting hire fleet of more than a hundred machines: excavators, cranes, tippers, loaders and lifts, doing around ₹50 crore a year, hired out to construction and infrastructure contractors with operators supplied alongside the machines.
They were not starting from nothing. A system from another vendor was already in place, and this was a migration to one built specifically for how a hire fleet of that size actually runs.
At that scale the hard part is not any single step. It is that the steps have to agree with each other. A machine's running hours are recorded on site. The invoice has to be built from those hours and no others. The invoice has to be filed with the government portal as a legal document. The same figure has to land in Tally as a voucher against the right ledger. Every one of those handovers is a place where a number can be retyped, and every retyped number is a place where the records stop agreeing.
The system the business runs on. It holds the fleet, the operators, the customers and their sites, and every hire agreement. Crews record each machine's daily running hours, fuel and breakdowns against the site it is standing on. At the end of each billing cycle the system builds the customer's invoice from those recorded hours, routes it for approval, files the GST e-invoice with the government portal, and posts the resulting voucher into the client's Tally accounts.
It has been live and in daily production use since August 2026, including e-invoicing against the real government portal rather than a sandbox, and a Tally bridge posting vouchers daily.
- 20
- Modules
- 55
- Screens
- 17
- Reports
- 9
- Dashboard alerts
- 3
- Roles
- 4
- Integrations
The screens below come from a demonstration database. Every company name, figure and document number in them is fictional.
The hire agreement
A work order per customer and site, with each machine on its own rate and billing unit (hourly, daily or monthly), its own overtime cap, and an operator charge where one is supplied.
A work order being edited. Every machine attached to it carries its own billing configuration, and the banner at the top is the guard: once an order is active, it takes an admin or owner to send it back to draft before any figure can change. The daily log sheet
One entry per machine per shift: opening and closing meter reading, fuel issued, notes. Hours run is computed from the readings, never typed.
The digitised log sheet. This is the record every invoice line is derived from, and the document you put in front of a client who disputes one. BreakdownsAutomatic
While a breakdown is open, running hours cannot be logged for that machine. On resolution the system fills every day of the gap with explicit zero-hours rows, carrying the meter forward.
The cycle closesAutomatic
The invoice drafts itself from the log sheets: hourly machines from summed hours, daily machines from distinct working days, plus operator charges, transportation, GST split by the buyer's state, and rounding.
Every invoice carries its own status, its e-invoice state and whether it has reached the accounts yet, all on one row. Owner approval
An employee or admin prepares and submits. Only the owner can release an invoice.
Once approved, the document is locked. Corrections go through a credit note rather than an edit. The e-invoice is filedAutomatic
At the moment of approval, with the government portal. The IRN, acknowledgement, signed QR code and signed invoice come back and land on the printed document.
The printed tax invoice, with the GST breakdown, the amount in words and the QR code rendered from the government-signed payload. The voucher reaches the accounts
Approved invoices queue for export as Tally vouchers with every ledger already mapped: the party ledger, each machine's income ledger, tax slabs and rounding.
Each mapping is decided once, against the real chart of accounts read out of Tally. Anything unmapped blocks the export rather than guessing.
What the system will not let happen
The same day can never be billed twice
A machine released mid-cycle has its billing window clamped on both sides. The contract it left counts the days up to the release, and the contract it joined counts the days after. Never both, never neither.
Downtime is recorded as downtime
Zero-hours downtime rows are excluded from billable days but stay visible, with the repair action and cost attached. A gap on the sheet says why it is a gap.
Nothing posts on a guess
An invoice whose ledgers do not all resolve is not exportable, and the worklist names the specific mapping that is missing.
Corrections follow the law, not convenience
Inside 24 hours of the IRN the e-invoice can be cancelled, and cancelled is terminal: never edited, never moved, kept permanently for audit. After 24 hours the route is a credit note, and the system says so.
Two shifts a day, and they may not overlap
At most two log sheet entries per machine per calendar day, re-checked on every edit. The work order, site, customer and operator are resolved by the server from the machine, not chosen by the person entering data.
Nothing happens unless a person asked for it
There is no scheduler and no background worker anywhere in this system. Nothing reaches the government portal or the books on a timer.
- Every figure on an invoice traces back to a specific day's entry, with a meter reading, an operator and a site behind it. That is what ends a billing dispute.
- The utilisation report distinguishes days that were billed, days sitting on a bill awaiting approval, days with work recorded but never invoiced, days with no activity, and days billed with no log sheet behind them. The third of those is the one worth having.
- Compliance stops being a surprise. Insurance, inspection certificates and operator licences are counted on the dashboard every morning, so a lapse is caught at a desk instead of at a client's gate.
Where every machine is, and what is about to lapse
The register holds each machine's type, model, registration and meter, its live status (available, deployed or broken down) and the contract and site it is standing on. Deployment is dated and kept as history, so where a machine was in August is a question with an answer.
One entry updates the store, the asset register and the accounts
A vendor invoice is recorded once. On save it raises the stock-in movements, updates each item's unit cost, creates asset records for what was bought, and queues the Tally voucher. Editing or deleting it reverses all of that, and refuses to if reversing would drive stock negative.
Seventeen reports, and the question each one settles
Five groups: billing, operations, assets, compliance and consumption. Every report takes a date range and the filters that matter to it, and every one exports to Excel with its totals as live formulas rather than flattened values.
Recognise your own process in this?
A 30-minute call is enough for us to tell you whether it's an automation, an ERP module, or a problem you shouldn't spend money on yet.