Software and systems · 28 Sep 2026

What can sawmill optimisation software do, and what can't it?

← Software and systems

It finds the highest-value way to cut each log, or each stem, from its scanned shape and a set of rules: product dimensions, grades, lengths and a price for each. It does this faster and more consistently than a person. What it cannot do is judge its own inputs. It works within the limits of its scanner and saws, and it doesn't know whether the prices in its file still match what the products sell for. That second limit is the one a mill can check from its own records.

What the usual answer says

The explanations that answer this question describe scanning and algorithms at each stage of the mill, and cite gains in recovery and value per log. The better ones already separate machine optimisation, which decides each cut, from planning against the order book, which decides what to cut today. What they don't cover is the price file both depend on, or how to check it against what the products actually sold for.

Optimiser price file value it assigns to each product Sales records average invoiced price for each product Different systems, so the comparison has to be built Gap per product each period Update the file owner, date, history Or set a limit demand, not price where the gap is large
The optimiser cuts to the prices in its file, and it cannot tell whether they still match what the products sell for. The check sets the two side by side, product by product, each period. Diagram: Quarri.

Optimisers trade volume for value, as instructed

The clearest field comparison comes from bucking in the forest, and the logic carries to the mill. A 2018 study by Eric Labelle and Linus Huß, in Silva Fennica, compared manual bucking by a harvester operator with the harvester computer's optimised suggestions in a spruce stand. Product recovery "differed by 4% in undamaged trees" in favour of manual bucking. Yet "the revenue of trees subjected to optimized bucking were up to 4% higher (in average 3%)" per cubic metre. In our reading, the optimiser gave up volume to earn value because that is what its price matrix rewarded.

That is the design. A 2025 open-source optimiser, BuckR, published in Forests by Caroline Bennemann and colleagues, lists what such a tool needs: it "requires tree data and product specifications with prices as the inputs". Change the prices and the same log is cut differently.

Each log is not the order book

An optimiser decides one log at a time. A mill sells orders, and orders mix products and dates. Cristian Palma and colleagues, in Mathematics in 2024, read here from the abstract, compared planning models that break customer orders into product totals with one that keeps each order whole. In a sawmill case study, the whole-order model "reduces costs by approximately 6% by enabling early order completion". It is a modelled saving in one case, and it comes from planning, which sits above the optimiser.

Scheduling against the order book is a different calculation from cutting each log, and it can be done fast. From Quarri's own work with a sawmill: a production scheduler re-solves an order book in about a second, and lands within 1 to 1.6% of the best possible schedule found by exhaustive search. The schedule and the optimiser need to agree on what the mill is trying to make.

Where the data goes wrong

Many mills update price files routinely, and vendors offer tools for it. The question is whether anyone checks the result. Ask when the price file was last changed, by whom, and against what. If lumber prices for one width have fallen since it was set, the optimiser keeps favouring that width. If a grade no longer sells at its premium, the optimiser keeps chasing it.

The other gap is feedback. The optimiser records what it predicted each cut was worth, and sales records what each product actually sold for. The two sit in different systems, so the comparison has to be built.

How to check it

Give the price file an owner and a date, and keep a history of every change. Then, each period, compare the value the optimiser assigned to each product with the average invoiced price for that product. Where the gap is large, the file needs updating, or the product needs a demand limit rather than a price.

Where open orders matter more than value per log, feed order quantities into the optimiser as limits or adjusted prices, rather than relying on list prices alone.

When it doesn't apply

Mills cutting to a fixed contract at fixed prices have less to check, though grade mix and by-product prices still move. Mills whose optimiser vendor updates price files from market data have part of this covered, though the check against invoiced prices still matters. The physical limits, such as scanner accuracy and sawline tolerances, are a separate subject, and title 22 covers how well grading scanners do. And the 2018 study was one stand with one harvester, so its 3% shows the direction of the trade, not its size elsewhere.

Quarri for sawmills is built around how a sawmill runs, from log intake to shipped order.

Sources

  1. Labelle and Huß, "Creation of value through a harvester on-board bucking optimization system operated in a spruce stand", Silva Fennica 52(3), 13 August 2018: silvafennica.fi
  2. Bennemann, Lussier and Labelle, "An Open-Source Tree Bucking Optimizer Based on Dynamic Programming", Forests 16(5), 780, 6 May 2025: doi.org
  3. Palma, Vergara and Muñoz-Herrera, "Explicit Modeling of Multi-Product Customer Orders in a Multi-Period Production Planning Model", Mathematics 12(19), 3029, 27 September 2024: doi.org
  4. Quarri evidence ledger, E21 (proven)

Quarri is an AI-native data platform for the timber supply chain. It connects buying, production, sales and inventory for forest management, sawmill, wood products and pulp, paper and packaging operators.

See it on your own data.

Live in two weeks, on the systems you already run.