Moving timber levies from paper to reconciled

← All case studies

A forestry group running several mills was reconciling timber levies by hand. Wood measurement data left the forest on paper and came back from the authority as PDF invoices, sometimes months after the load was scaled, and somebody matched the two across about 116 files every cycle.

3+ days a month

Of manual matching and error chasing handed back to the finance team, on the operations lead's own estimate. Alongside it, an over-accrual credit of about $80k surfaced in a single release cycle.

Who we met

The finance side of a forestry group with mills of its own, upstream harvesting, and a levy bill running to hundreds of thousands of dollars a month. Three people read the same workbook each cycle and usually found something between them. Nobody had it down as a reconciliation problem. It was month-end.

We've never had a proper reconciliation workflow. Because we run so lean.

Operations lead, forestry operation

What made it hard was not arithmetic. The field ran on paper, the system of record was a slow legacy ERP, and the interface with the authority was PDF in both directions. Between those sat Excel, holding the rate tables, the department mapping and a fair amount of judgement encoded in cells that one or two people carried in their heads.

What we did

We started with the people rather than the data, because in an operation this size the rules live in somebody's head and in a spreadsheet cell, not in the system of record.

A roadside deck of cut logs stacked end on, hundreds of sawn faces of varying diameter — Every log end here becomes a line on a bill of lading, a weight on a scale ticket and, eventually, a charge on an authority invoice.

The workbooks are the specification

Interviews with the forester, the administrators and the finance team, then a proper read of the workbooks they had built. Whatever the ERP holds, those workbooks are where the rules of the job had ended up.

From there we connected the load, weigh and invoice sources, cleaned and modelled them so a load, a weight and a charge could actually be joined, and built a semantic layer carrying their vocabulary rather than ours.

Classification was the part that needed the most care. Which approval a load was cut under, which gate it went through and what status it was sitting at all change what it owes, and none of that was written down anywhere. We took it out of conversation and out of spreadsheet cells and put it into reference tables the operation edits itself, with variance tolerances they set rather than us.

Then we built to it. Scanned invoices read per bill of lading, deterministic parsing so the same document reads the same way next cycle, and a posting file at the end that finance can use rather than retype. Their team runs it. We do not run it for them.

What we left them with

A reconciliation that works at the level of the individual load rather than the monthly total, which is the difference between a number you can book and a number you can explain.

Paper in, exceptions out.

// Illustrative · not the customer's ledger

// Documents inread, not retyped

The month arrives as paper and scans. Nobody at the operation reads a document to get a number out of it any more, and what cannot be read cleanly is raised rather than filled in.

// Summary levellooks tied

Compare two totals and a timing difference, a rate error and a load that never should have been charged all look identical.

// Bill of lading level1 exception

The same month, checked per load. What washes out of a total has to declare itself here.

Matching at load level against their own tolerances means a timing difference and a rate error stop looking alike. Anything that cannot be matched ages in view instead of being absorbed into a total, and anything that cannot be read cleanly is raised rather than filled in.

The result

3+ days/moOf manual reconciliation and error chasing returned to the team, on the operations lead's own estimate

+$80kOver-accrual credit surfaced in a single release cycle

+$760kOf accrued balance released against actual invoices in that same cycle, rather than carried as an estimate

500%+Surcharge rate gap caught, $1.50/t accrued against $9/t invoiced

One release cycle in the first quarter of 2026, inside a rolling ledger spanning eight months. Computed by Quarri from the operation's own load, weigh and invoice data, checked back against the source PDFs, and reviewed by their finance team before anything was posted.

Time3+ days a month

Manual matching and error chasing, back with the people who were doing it. That's their estimate rather than our measurement, and it's the one we'd trust, because they were the ones doing the matching.

Margin+$80k credit

An over-accrual credit in a single release cycle, and a fuel surcharge accruing at $1.50 a tonne against $9 invoiced, caught before it compounded across every load it touched. A timing difference washes out next month. A rate that's wrong stays wrong.

Cash+$760k released

Accrued balance released against actual invoices in that one cycle rather than sitting on the balance sheet as an estimate. The value isn't the number. It's that the number is now the real one, and it arrives in days.

Six months in, the operation took the approach to the regulator's wood measurement modernisation working group and presented it alongside us. That was their idea rather than ours, and it's the reference we'd point to first. There's more on the upstream side of this on the forest management page.