Cost per block

Why per-block cost control matters today

Per-block cost control is no longer an accounting luxury. With Chilean export fruit at record volumes —the 2024-2025 season shipped the largest cherry crop to China on record, according to Frutas de Chile— and real labor costs climbing every season, the farm-wide average cost is no longer enough to make decisions. A 10-15% gap in cost per kilo between two neighboring blocks changes which fruit should go to the spot market and which to grower return.

The expensive decisions —renewing a variety, pulling plants, reallocating water or crews— are made at the block level, not the farm level. You need the figure at that same resolution, because that resolution is where you make or lose money.

That figure also has to be available mid-season, not at close. When per-block profitability analysis lands six months after harvest, you have already shipped the fruit, already paid the labor, and it is too late to fix anything. Per-block costing is the operational half of the profitability equation: it connects directly to per-block P&L, where cost meets actual return. Without an up-to-date cost, the margin per block is a black box you only open once you can no longer act on what is inside.

The real problem (no marketing)

The cost spreadsheet fails for predictable reasons, not bad luck. In an export operation with several farms and dozens of blocks, a single person usually owns cost control in Excel; when that person goes on holiday, gets sick, or rebuilds the file each season, the data falls behind or breaks. Chile's fruit industry runs on margins that ODEPA has reported under sustained pressure since 2023, and that context does not forgive weeks lost to a data-entry error.

The breaking points are always the same:

The result is a number nobody fully trusts. When a field manager argues that his block can't cost that much, he is often right: the cost loaded machinery hours that actually went to another block, or a batch of inputs split across three different blocks. Without traceability back to the work order that originated each expense, that argument isn't settled with data — it's settled by hierarchy. And meanwhile you choose which block to harvest first or which crew to pay piece-rate with costs that, if you can't see them in real time, you end up estimating from memory.

How this module solves it

The cost-per-block module assigns every expense to the block where it actually occurred and surfaces cost per hectare, per kilo, and per plant at any point in the season, not at the annual close. It feeds automatically from the source modules —labor, inputs, machinery, services— and applies configurable rules to distribute shared costs, so that a higher cost per kilo can always be explained with a concrete fact.

When you run a work order in a block, that task already carries the crew that performed it, the machine hours, and the inputs it consumed. Labor comes from the workforce module, materials from inventory, and machine hours from machinery:

1. 01

   You run the task in the block

   A pruning, a spray application or a tractor pass is recorded with its crew, machine hours and inputs at the moment it happens.

2. 02

   It is costed automatically

   The module takes that record and assigns it to the right block with no re-entry. Every peso lands where it occurred.

3. 03

   You see cost per kilo, live

   Cost per hectare, per kilo and per plant stays current, and the block ranking reflects the season in progress, not the last one.

Costs that don't belong to a single block —irrigation from a shared main, the supervisor's salary, farm administration— are split with rules you define once and that stay visible to everyone: per hectare, per plant, or per water use, whichever makes sense for each cost type. Instead of an improvised allocation each season, you have a stable, debatable criterion.

Integration with your current stack

The module doesn't aim to replace your ERP: it coexists with it. It exports to the accounting system —SAP Business One or Defontana in most Chilean operations— to reconcile at formal close with no double entry, and it connects to the tools your team already uses:

The piece that makes all of this work is shared master data. Blocks, varieties, inputs, and workers are defined once and every module uses them the same way, so the cost you see on the dashboard matches the one you export to the ERP and the one that appears in traceability. Without that common master data, integrating systems comes down to reconciling spreadsheets by hand —which is exactly the work you are trying to eliminate. With it, every system speaks the same language about the same blocks.

Metrics you'll move

The three metrics the module keeps current are cost per hectare, cost per kilo, and cost per plant for each block. For export fruit, cost per kilo is the one that rules: it's what you compare against the destination market's expected return to decide, block by block, which fruit justifies the freight to China and which is better sold closer to home.

Seeing them in-season, rather than at close, is what separates deciding from guessing. Each indicator moves from being calculated at year-end to being visible this week, and each one unlocks a concrete decision:

Knowing that a block runs 20% above the average cost per kilo tells you where to look before you ship, not after. For an exporter with multiple farms, that ranking applied to dozens of blocks is the difference between managing by exception —attacking the five blocks bleeding money— and reacting at close, when there's nothing left to adjust. Operations moving from spreadsheets to automated costing tend to report close-time reductions on the order of 10-20%; the exact figure depends on how manual your prior process was.