Ledgerline

Before a team buys anything, the finance process is almost always the same shape. One spreadsheet holds the invoice log, another holds the PO numbers, the receipts sit in a shared drive, and the approvals live in an email thread that exactly one person can reconstruct. It holds together until that person takes a week off.

The cost is rarely one dramatic failure. It is a duplicate payment nobody spots until the supplier mentions it, an invoice signed off by someone who was never authorised to approve that amount, a receipt that never got matched back to its PO, and a quarter-end where three days go into rebuilding a story the system should have kept on its own. We built Ledgerline against those four failure modes, in that order.

01 What does Ledgerline replace?

Ledgerline replaces the spreadsheet-and-email-thread stack: the invoice register, the PO log, the approval thread, and the folder of receipt scans. Those four artefacts are one workflow split across four tools that cannot see each other, which is why the reconciliation work exists at all. Put them in one place and most of that work stops being work.

The spreadsheet is not the villain here. A spreadsheet is an excellent thinking tool and a poor system of record: it has no concept of who is allowed to change a number, no memory of what a cell said last Tuesday, and nothing to stop the same invoice being keyed twice on two different tabs. Ledgerline keeps what spreadsheets are good at — export, ad-hoc analysis, a grid a human can read — and takes back what they are bad at: control, history, and routing.

02 How do approval chains work?

Approvals are the heart of it. Every document moves through a configurable chain — who can raise, who must approve, at what threshold — and every step is recorded, so nothing depends on somebody remembering to forward an email. Approval chains are configured per document type, so an invoice and a purchase order do not have to inherit the same routing just because they pass through the same desk.

The threshold is what makes a chain useful rather than ceremonial. A small stationery invoice and a five-figure contractor invoice should not travel the same path, and in most teams they do, because the path is "ask Sarah". Below is the shape of schedule we configure most often. The numbers are yours to set; the structure is the part that matters.

The rule we argue for every time: no self-approval, at any threshold. It is the cheapest control in finance operations and the one most quietly broken by a spreadsheet process, because a spreadsheet has no opinion about who typed the row.

What happens when an approver is away?

Absence is what breaks the inbox process hardest, because a pending approval sitting in one person's inbox is invisible to everyone else. In Ledgerline a waiting document sits in a queue with a name against it, so the team can see what is outstanding and on whom without asking. Chasing becomes a list instead of a guess.

03 What does purchase-order and receipt matching catch?

PO and receipt matching catches the discrepancies that quietly cost money — the ones nobody notices because each document looks fine on its own. Three-way matching is the practice of comparing what was ordered (the purchase order), what arrived (the receipt), and what is being billed (the supplier invoice) before any payment is released. Most small finance teams do this from memory, which works right up until volume or staff turnover removes the memory.

Four discrepancies account for most of the leakage:

• Quantity mismatch. Twelve ordered, ten delivered, twelve invoiced.
• Price creep. The invoice unit price is not the price on the PO, and the gap is small enough to wave through.
• Duplicate invoice. The same supplier reference arrives twice, by two routes, and both get paid.
• No PO at all. Spend that never went through a purchase order, which means it never went through an approval either.

Matching turns each of those from a discovery into a flag. A flagged document stops in the chain rather than continuing towards payment, and finance reviews the exception instead of re-auditing everything else to find it.

04 What does an auditor actually see?

An auditor sees the document and its full chain: who raised it, who approved it, in what order, and when. Every step is recorded, so an auditor's question has an answer that is one click away rather than one archaeology project away.

The question an auditor asks is rarely "show me the invoice". It is "show me that this invoice was approved by somebody who was allowed to approve it, before it was paid". That is a question about sequence and authority, and it is precisely the question an email thread cannot answer, because inboxes are personal, deletable, and unordered across people. A recorded chain answers it the same way every time, for every document, without anyone preparing for the visit.

Role-based access exists for the same reason. Approvers, viewers, and the finance team see different surfaces, so you can give an external accountant sight of the ledger without giving anybody the ability to change a number in it. Read-only is a feature, not a limitation.

05 Where does Ledgerline sit between a spreadsheet and an ERP?

Between them, deliberately. A spreadsheet is free and immediate and has no controls; an ERP has every control and takes months plus an implementation partner to reach a first useful day. Most teams hit the point where the spreadsheet stops being safe long before they are large enough to justify the ERP, and that gap is where Ledgerline lives.

Our position, stated plainly: if you already employ somebody whose job title is the ERP, buy the ERP. If your finance function is a handful of people serving dozens of budget owners, an ERP will cost you more in implementation than the problem costs you today — and the spreadsheet is already costing you more than you have measured.

06 What do the reports actually tell you?

Reporting turns the resulting ledger into something a non-accountant can actually read. The three questions it answers are the three a finance lead is asked every week: what is waiting and on whom, what was approved in this period and by whom, and where matching keeps failing often enough to be a supplier conversation rather than a clerical one.

Export is part of the same job. A tool should not hold your numbers hostage, and the board pack is going to be assembled in a spreadsheet regardless — the difference is that the spreadsheet is now downstream of the system of record instead of being it. When a team wants Ledgerline data moving into other systems they already run, we scope that as platform and AI integration work rather than pretending it is a checkbox in the app.

07 How Cordytech builds and runs Ledgerline

We build it, we run it, and we are on the other end of it. Ledgerline comes out of the same practice as our custom web application development engagements: server-rendered, tested on behaviour rather than coverage numbers, with the audit trail switched on from day one — because retrofitting one is how a team ends up with a gap it cannot explain.

Ledgerline is demo-led and live today. There is no self-serve sign-up: we walk you through it against your real process, configure the approval logic to match how your team already works, and stand it up. That order is deliberate. A finance team configuring its own approval thresholds at 11pm during a free trial will configure them wrong, and nobody finds out until an auditor does.

It is the reference build for how Cordytech ships operational software — opinionated where it should be, configurable where it must be, and honest about the workflow it is replacing. Fieldshift, our field-service workflow app, is built to the same standard for a different kind of team, and you can see everything we build and run side by side. If the spreadsheet-and-email-thread process described above is your process, request a demo and we will run it against your documents rather than ours.