How do scale house systems and ERPs share data?

A weigh ticket passes from the scale system to the ERP as a record: gross, tare and net weight, date and time, truck, product, species, and a contract, tract or supplier. The ERP then turns weight into volume and money, using a price per ton or a conversion factor, and books the cost or the payable. The transfer itself is the easy part, whether by file, API or middleware. The integration succeeds or fails on two things: the keys typed at the scale and the conversion applied in the ERP.

What the usual answer says

Descriptions of scale-to-ERP integration promise automatic transfer of weigh tickets. They say this ends double entry, reduces errors and speeds settlement. That is true for the typing. It says nothing about whether the ticket reaches the right account, or whether the ERP values it correctly.

The keys

A ticket is useful to the ERP only if it carries identifiers the ERP recognises: the contract or purchase order, the tract or sale, the product and species, and the supplier or logger. At the scale, those are chosen from a list or typed in by the scaler, often under time pressure with a truck waiting. A tract number typed with a transposed digit, or a product code for the wrong grade, transfers perfectly and lands in the wrong place.

In our experience the check is simple and often skipped. Before tickets post, match every key against the ERP's open contracts and products, and hold any ticket that doesn't match in a visible queue. Then track the count of held tickets each week.

The conversion

Where logs are bought by weight but valued, sold or reported in volume, the ERP applies a conversion factor. An extension publication reprinted in 2026, adapted by Brady Self from an earlier guide, says "mills typically establish a fixed conversion factor when buying logs", and that for hardwood sawlogs "These conversions are usually somewhere between 8 and 9 tons per MBF". Its tables, based on a 2006 study, show the factor is not a constant. Average hardwood sawtimber runs from 12.1 tons per thousand board feet at 14 inches in diameter to 6.8 at 36 inches, with board feet on the Doyle rule, which the same page says tends to "underestimate lumber yield in small-diameter logs". So much of that fall comes from the log rule rather than the wood. The publication draws the cost consequence itself: "The assumption that tons per MBF is a constant will result in lower cost per MBF of sawn lumber for large-diameter logs and a higher cost for those of smaller diameter".

Diameter is not the only cause. The publication lists density, log position, species, site, genetics, season and drying time. It notes that density varies, "with logs of the same diameter and species ranging as much as 40 percent in some cases", and that "as logs dry, weight per board foot decreases." Its advice to landowners with large-diameter timber is to consider buying on volume rather than by the ton.

The volume figure itself is an estimate. Ed Thomas and Neal Bennett's 2017 study, simulating 32 hardwood logs, found recovery from 31.9% under to 159.4% over what common log rules predicted (our #47 covers this in depth). A weight-to-volume factor stacks one estimate on another.

What that means for the ERP

For settlement, the contract factor is right by definition: both parties agreed to it, and the ERP should pay what the contract says. The trouble starts when the same factor feeds cost and yield analysis. For hardwood sawlogs bought by weight, an ERP that applies one factor to every ticket misstates the volume of small-log and large-log loads in opposite directions. Over a month, the errors may cancel in total and still misstate cost by supplier, tract or product.

A better setup keeps weight as weight in the ERP, since weight is what was measured. The contract factor drives the payable. Any conversion used for costing is stored separately, as a factor with a product, a size class where known, and a date. That lets the business compare converted volume with what the mill later tallies, and adjust the factors from its own data.

The reconciliation

Each period, total the tickets by contract and supplier in the scale system, and total the same in the ERP. They should match exactly in weight. Then compare converted volume with the volume the mill measured for the same logs, where it can be traced. The first check finds transfer and key errors. The second finds conversion errors, and over time it builds factors that fit the business's own wood.

AI helps where tickets are paper or handwritten, by reading them into records. It also helps with checks no one has time for by hand. A model can flag a ticket whose net weight is far above that truck's usual loads on the same contract, which often means a mistyped truck or a load booked to the wrong tract.

When it doesn't apply

Operations that buy and pay entirely by weight, and report in weight, have no conversion to manage, though the keys still matter. Pulpwood bought by the ton and consumed by the ton is the common case. And where the scale system and the ERP are one product, the transfer disappears but the conversion question does not.

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

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.