Skip to main content
Partner Stories

Multi-Entity Consolidation on Dynamics 365 Business Central for Agricultural Holding Companies

Key Takeaways

For readers who want the short version first:

  • The structure the ERP has to carry. Land, equipment and operations are routinely split across three to fifteen entities for liability, tax, estate and co-op reasons, and that structure is the starting point for the configuration.
  • Business Central handles the common cases well. Intercompany journals, cross-company sales and purchase documents, consolidated financial statements across companies on different fiscal years and currencies, and shared chart of accounts through a consolidation company all work out of the box.
  • Several things don't work out of the box for agriculture: physical commodity transfers between entities, labor split across entities for the same crew on the same day, equipment depreciation shared across entities, and consolidation across entities that run on both fiscal and crop-year calendars.
  • A handful of configuration decisions do most of the work: dimensions for entity, crop and field; intercompany posting setup for commodity movements at cost; a consolidation chart with ag-specific accounts; and a consolidation-only company for period mismatches.
  • An ag ISV is required for grower settlements, pooling and load-level grain positions. Native Business Central plus configuration doesn't cover grower accounting or patronage distribution.
  • Start with the entity map. The decisions that cost the most to redo are the dimensions model and which company is the consolidation parent.

Introduction

Most mid-market farming operations are not one company. They are a holding structure, with land in one entity, equipment in another, farming operations in a third, and often a separate packer, sales company and co-op membership entity on top.

The business case for running agriculture as a group of entities is a separate conversation, which the companion piece on multi-entity farm accounting covers in more detail. This one assumes the structure already exists. It walks through what Business Central does out of the box, where it stops being enough for agriculture, how to set it up for an ag holding group, and when a specialist ISV earns its place.

The Reason Agricultural Operations Are Structured This Way

The multi-entity structure is older than most of the software that has to carry it. Land is held in its own entity for liability and estate planning, and because the land often outlives any one operating business. Equipment sits in another, for depreciation and for the same liability reasons. The farming operation leases both from the holding company at a market rate, which is how value moves between the entities for lender and IRS purposes. A packer or a sales company may sit alongside the farm as a separate entity, because co-op membership is restricted to producers, because the packer carries food-safety liability the farm shouldn't absorb, and because the two have different margin and tax profiles. A parent LLC on top gives the family one place to see consolidated results and to move capital around.

Three to fifteen operating entities is a normal range. The ERP work isn't about convincing anyone to simplify this; the structure exists for reasons the controller is not going to overturn. The work is making it readable in one set of financials.

What Business Central Already Handles for a Holding Group

Before the gaps, it's worth giving the platform its due. On a stock installationation, the hard parts of multi-entity accounting listed below are already handled.

Intercompany journals and documents

Business Central has a built-in intercompany framework that posts the matching entries in the counterparty company when a transaction is created in the source company. Since the 2023 wave 2 release, intercompany transactions can run across separate Business Central environments, which matters when subsidiaries have their own tenants for legal or audit reasons. Sales orders, purchase orders and general journals all work this way.

Consolidation across fiscal years and currencies

The consolidation framework handles subsidiaries that close on different fiscal years and that report in different currencies. Microsoft's documentation on consolidating financial data from multiple companies walks through the setup, including how to translate balance sheet and income statement accounts at the right rates.

A consolidation company as a single reporting layer

A dedicated consolidation company holds the group chart of accounts and pulls balances from each operating company at close. The operating companies keep their own charts, which can differ, and a mapping table lines each operating-company account up to a consolidation account. For an ag group where the farm's chart looks nothing like the packer's chart, this layer is the point.

Dimensions as the structural layer under the chart of accounts

Dimensions let the same account carry entity, crop, field, cost center and project without exploding the chart into thousands of GL codes. The 2025 release waves added further enhancements to no-code financial reporting, which closed one of the last gaps for groups that report by both legal entity and operational dimension.

Intercompany eliminations in the consolidation company

After balances come across, duplicated entries have to be eliminated so group revenue isn't double-counted and intercompany receivables don't inflate assets. Business Central's elimination process is documented but manual: a group controller enters elimination journal lines in the consolidation company, runs the G/L Consolidation Eliminations report to simulate the result, then posts. The Intercompany Transactions report is used to reconcile that Entity A's receivable from Entity B matches Entity B's payable to Entity A. One limitation worth flagging: elimination of profit in ending inventory, which comes up when the packer still holds grain bought from the farm at a mark-up, is not automated and requires either a manual adjustment at close or an ISV. For most ag groups the manual process is workable; for groups with heavy intercompany volume it is one of the first places an ISV earns its place.

That covers the common cases for a holding company. Several more don't work the same way for agriculture, and that is where configuration decisions start to matter.

Where a Standard Setup Falls Short for Agriculture

Physical commodity transfers between entities

Grain, potatoes or produce move from the farming entity to a storage or packing entity on the same day they come off the field. On the books, that is a sale from one legal entity to another, so an intercompany invoice posts, revenue hits the farm's books, and inventory lands on the packer's books. The accounting is clean. The physical reality isn't: it is the same lot, with the same harvest date, the same field of origin and the same traceability data. Native Business Central doesn't carry lot attributes or harvest-ticket data through an intercompany sale. A load has to be re-received, re-lotted, and the field-of-origin link has to be rebuilt in the receiving company. For an operation that owes a sortable traceability spreadsheet to the FDA under FSMA 204, that is a problem to solve, not to live with.

Labor allocated across entities for the same crew on the same day

A field crew spends the morning harvesting for the farm entity and the afternoon in the packhouse for the packer entity. Payroll runs out of one entity, usually the operating company, and the time has to be split across entities with intercompany recharges at the loaded cost rate. Business Central's resource allocation handles the posting side, but the hours capture needs a time-entry process that records the entity against the hour, not against the employee. That is a mobile app and a process, not an ERP feature.

One point to settle before the time-entry process is designed: the payroll tax and workers' comp treatment of a split day is a policy decision the group's CPA has to make, because the software can post whichever allocation the policy dictates but it cannot choose the policy.

Shared equipment depreciation

A $400,000 harvester sits in the equipment holding entity, which depreciates it. The farming operations entities use it and are billed at an hourly rate. Business Central handles the posting side with intercompany, but there is no native way to track machine hours against the users and to generate the recharges automatically. Groups end up with a spreadsheet that nobody wants to own, and the recharges either lag or get missed.

Period mismatches between fiscal and crop years

A fiscal year ends December 31. A crop year ends when the last potato is out of storage, which could be May. Growers who book sales into a pool close that pool months after the fiscal year closes. Business Central's consolidation handles different fiscal years between entities, but it doesn't handle an entity that runs on two overlapping calendars at once. The accrual between the two needs manual work at close.

None of these is a reason to walk away from Business Central. The gaps split into two kinds, which matter because the fixes are different. Commodity transfers and period mismatches are data-model gaps: Business Central's data model doesn't represent the concept, and the fix is a configuration pattern or an ISV extension. Labor allocation and shared equipment depreciation are process gaps: Business Central can post the result, but the input process needs a mobile time-tracking tool or a machine-hours capture app alongside the ERP. Naming which kind a given gap is tells you how heavy the solution has to be.

Setting Business Central Up for an Ag Holding Group

For ag holding groups that live inside standard Business Central with careful configuration, a handful of patterns do most of the work.

Dimensions for entity, crop and field, set up at the group level

The temptation is to let each operating company define its own dimensions. On an ag group, that breaks consolidation reporting, because the farm's "field" dimension values don't match the packer's. The pattern that holds is to define entity, crop, field, cost center and (where relevant) grower as group-level dimensions in the consolidation company, with the operating companies drawing values from the same list. One transaction then carries the holding-company view and the operational view at the same time, and a report by field across all entities actually works.

Dimension

Example values

Purpose

Entity

Farm LLC, Packer LLC, Equipment Co.

Legal and consolidation view

Crop

Potatoes 2026, Corn 2026, Wheat 2025

Crop-year reporting

Field

North 40, River Bottom, Hogback

Field-level cost and profitability

Cost center

Harvest crew, Packhouse, Shop

Operational cost allocation

Grower

Self, Grower A, Grower B

Third-party grower settlement

Intercompany posting setup for commodity movements, at cost rather than at a transfer price

When grain moves from farming to storage, the intercompany sale should post at the farming entity's actual cost, so the packer's inventory lands valued correctly for its own costing downstream. Business Central's intercompany partner setup can route the posting, but the cost source has to be configured explicitly. The default behaviour will post at the sales price, which breaks margin reporting on the packer's side.

A consolidation chart with ag-specific accounts

Native Business Central doesn't ship with grower advances, settlements payable, crop inventory at harvest cost, deferred patronage or pool liability accounts. Add these in the consolidation chart first, then map the operating-company accounts to them. Trying to force an ag account into a stock SMB chart later is harder than designing it in.

A consolidation-only company for period mismatches

The cleanest pattern we have seen for the fiscal-versus-crop-year problem is a consolidation company that re-maps each operating entity's periods onto the group fiscal year. The operating entities keep their own calendars (fiscal, crop year, or both), and the consolidation company holds the adjusting entries that bring everything onto the group's December 31. A design note on how it actually runs: the consolidation company carries the group chart of accounts, not the parent's operating chart, so adjusting entries live separately from any transactional books. The adjustments post as recurring journals owned by the group controller, with crop-year balances held in a dedicated reclassification account until the pool closes and then reclassified into the correct fiscal period. The audit trail sits on those journal entries. It works because the consolidation company is doing nothing else.

These patterns cover the common cases. The ones they don't cover are the ones that put a specialist ISV on the shortlist.

When a Specialist ISV Earns Its Place

The configuration patterns above handle a holding structure that farms, packs and sells. Three additional capabilities push a group beyond what native plus configuration can carry.

Grower settlement accounting

When the parent group buys from third-party growers as well as its own farms, each delivery generates an advance at harvest and a final settlement after the pool closes, often months later. Native Business Central posts the GL side cleanly, but it does not carry the ticket-by-ticket detail that produces a grower statement, and it does not calculate pool prices across thousands of tickets.

Patronage distribution

Co-ops and co-op-structured groups distribute margin back to members based on patronage, by product and by period. The calculation is specific enough that it belongs in software designed for it rather than in GL journals.

Load-by-load grain positions

For a grain operation, the ERP has to track open contracts, position by delivery, settlement matching per load, and basis against the futures market. Business Central's inventory and sales modules were not built for this; it needs a grain-specific layer.

For groups that need any of these, AgriERP on Business Central extends the platform to carry them while leaving the native intercompany, consolidation and dimensions framework intact. A verified reference is the Grant 4D case study, a potato grower whose consolidation run itself dropped from a multi-week spreadsheet exercise to about ninety minutes on AgriERP on Business Central, with the full monthly close now running at five to seven days.

Groups large enough to need Finance and Operations rather than Business Central have a different option. Levridge is an agriculture layer on Finance and Operations, built for grain, ag retail and larger farm operations. It is not a Business Central ISV, but it belongs in the shortlist for a group whose scale has already moved it to the larger platform.

Where to Start If You're Setting This Up Now

For a consultant or controller walking into a fresh implementation of this shape, the order of decisions matters more than the pace.

Start with the entity map. On a single page, list every legal entity, its purpose, which ones hold which assets, which ones transact with each other, and which ones consolidate up to the parent. Agree it with the client's tax advisor before anything is built, because every later decision follows from it.

Next, design the dimensions. Entity, crop, field, cost center and grower are the ones that recur. Set them up as group-level dimensions in the consolidation company before any transactional company goes live, so the operating companies draw from the same list from day one.

Build the consolidation company third. Decide which entity is the parent, which chart of accounts it carries, and how it will map each operating company's accounts into it. Any ag-specific accounts the group needs belong in this chart first.

Set up intercompany partners last, because by then the chart and the dimensions are stable. Configure commodity movements to post at cost, and test with a dry run against the current year's figures before the operating companies cut over.

The decisions that cost the most to redo are the dimensions model and the choice of consolidation parent. Everything else is reconfiguration; those two tend to be rebuilds.

AgriERP on Business Central

AgriERP is an agriculture ISV built on Dynamics 365 Business Central, developed by Folio3. It extends the native platform with grower accounting, pool settlements, patronage distribution, GS1-128 traceability and grain position tracking, for farm and handler groups that have outgrown a stock installationation.

Frequently Asked Questions

Can Business Central consolidate companies with different fiscal years?

Yes. The consolidation framework supports subsidiaries that close on different fiscal years and that report in different currencies. The consolidation company holds the group chart of accounts and translates balances from each operating company at the correct rates. See Microsoft's documentation on consolidating financial data from multiple companies for the setup.

Does Business Central handle intercompany between separate environments?

Yes. Since the 2023 wave 2 release, intercompany transactions can post across separate Business Central environments, which matters for groups whose subsidiaries have their own tenants for legal or audit reasons.

What is the difference between Business Central and AgriERP for multi-entity agriculture?

Business Central provides the intercompany, consolidation, dimensions and chart-of-accounts framework. AgriERP is an ag ISV that sits on top of Business Central and adds grower settlement accounting, patronage distribution, pool pricing, GS1-128 traceability and load-level grain positions. A holding group with those requirements uses both; the choice isn't native-or-AgriERP, it is native-only or native-plus-AgriERP.

How many entities can Business Central consolidate?

There is no hard-coded limit, but the practical range is three to fifteen operating entities. Beyond that, consolidation run time, intercompany reconciliation complexity and the consolidation company's data volume become management challenges rather than feature constraints. Groups approaching twenty entities should model the consolidation process before committing to it. For reference, the Grant 4D case runs an eight-entity consolidation on AgriERP on Business Central in about ninety minutes.

How long does a multi-entity Business Central implementation take, and what does it cost?

For a group of three to eight entities with a reasonably clean chart of accounts and standard intercompany flows, three to six months is a realistic range: two to four weeks on the entity map and dimensions design, two to three weeks on the consolidation company build, and one to two weeks per entity pair on intercompany setup and testing. Adding an ag ISV such as AgriERP extends the schedule by the ISV's own implementation, usually one to three months in parallel. Services cost scales with the same drivers; for a mid-market ag group it typically runs $75,000 to $200,000, with ISV licensing on top.

What's the role of dimensions in a multi-entity ag setup?

Dimensions carry the operational view (entity, crop, field, cost center, grower) under the same chart of accounts, so the same transaction can be reported at the holding-company level and sliced by field or crop across the group. Setting them up at the group level, before any operating company goes live, is the single decision that prevents the most rework.