|
Getting your Trinity Audio player ready...
|
From Containers to Consolidation: How Business Central Supports Multi-Entity Commodity Trading
A practical view of the workflows commodity traders actually need – multi-currency finance, variable units of measure, landed cost, intercompany trading, regional controls, banking, and group reporting.
Commodity trading looks simple on paper: buy a product in one market, move it, and sell it in another. In practice, the finance and operations model is much harder. A single trade can cross legal entities, currencies, tax regimes, units of measure, ports, warehouses, and internal counterparties before the group can see the true margin.
Consider a multi-country commodity trading group with a headquarters entity, regional operating companies, local resale, intercompany purchases and sales, deal-by-deal pricing, daily exchange rates, landed costs, country-specific compliance, and consolidated financial reporting. The ERP challenge is not generic accounting; it is preserving transaction detail in each legal entity while giving group finance a consistent view of the trade.
The Key Implementation Question
Can one ERP preserve the detail required by each local entity while still giving group finance a clean, consolidated view without re-keying transactions or inflating sales and purchases?
1. Commodity master data must reflect how the product is actually traded
Commodity businesses rarely transact in one neat unit. A cargo may be contracted in metric tons, moved in full-container loads, received into a local operation, and sold in 50 kg bags. A practical ERP design therefore needs to support bulk purchasing and intercompany movement at one level, followed by local sales in smaller units without losing quantity or valuation integrity.
Business Central can model a base unit of measure and additional item units with conversion factors. In a commodity implementation, that means a product can be managed with a base quantity such as kilograms while transactions use tons, bags, or other commercially relevant units. The item master also provides the foundation for item category, costing method, posting groups, dimensions, and inventory controls.
The design decision is important: do not treat “sugar,” “grain,” “coffee,” or “pulses” as a single generic item if grade, origin, specification, crop season, packaging, or quality attributes affect valuation and commercial reporting. The standard Business Central screen below shows the Item Units of Measure page, where alternate units and conversion factors are maintained for an inventory item. In a commodity design, the same standard pattern can be used for combinations such as KG, BAG, and MT.
-
Deal Pricing Should Stay Flexible – Because Commodities Are Not a Supermarket Price List
Commodity pricing rarely behaves like a fixed retail price list. Prices can change by season, origin, quality, shipment, market movement, counterparty, and the individual negotiation.
Business Central supports standard pricing and discount structures, but a commodity implementation should not force static price lists where the commercial reality is negotiated trade-by-trade. Purchase and sales documents can carry transaction-specific prices and discounts, while approvals, references, and dimensions provide governance around those deals. For disputes, claims, quality adjustments, or negotiated settlements, the model should preserve the reason for the adjustment rather than burying it in an unexplained price override.
-
True Margin Starts With Landed Cost, Not the Supplier Invoice
The purchase price of a cargo is only the beginning of its economic cost. Freight, clearing, insurance, port charges, inspection, handling, and other logistics costs can materially change margin. Business Central item charges can be used to associate these additional costs with purchased goods so inventory value and cost of goods sold better reflect the economics of the trade.
For a commodity trader, the key is to move from invoice price to fully landed cost. In Business Central, freight, insurance, port handling, clearing, inspection, and similar costs can be captured as item charges and assigned to the relevant purchase receipt or item entry. Those charges increase the inventory cost basis and can flow into cost of goods sold as the inventory is sold. This produces a more accurate basis for margin analysis. With the appropriate dimensions, lot or trade references, and commodity-specific attributes, the business can then analyze profitability by commodity, origin, shipment, or entity.
Example: if a sugar cargo is purchased at USD 480 per metric ton and later attracts freight, insurance, port, clearing, and inspection charges, those costs should be allocated back to that cargo. Management can then compare the eventual selling price against the fully landed cost per ton rather than against the supplier’s invoice price alone.
- Intercompany Trading Is Where ERP Design Either Removes Work – or Creates It
A multi-entity commodity group often has a trading hub that buys from or sells to regional companies, while those same subsidiaries may also transact locally. If every side of an intercompany deal is keyed independently, finance teams spend time reconciling documents that should already agree.
Business Central has intercompany functionality for partner companies, intercompany charts of accounts, dimension mapping, and inbox/outbox processing. Partners can enter a transaction once and create the corresponding document in the other company. Where Auto Send and Auto Accept are configured, incoming and outgoing intercompany transactions can be processed with less manual intervention; automatically created intercompany journal lines are still not posted automatically. The design objective is to avoid re-keying while preserving control over what is accepted and posted.
However, commodity groups should distinguish normal intercompany trading from more complex funding relationships. Advances to subsidiaries, loans, shared expenses, and amounts that are later recovered from profit can require a more deliberate settlement design. Those scenarios should be validated in fit-gap rather than assumed to behave like a simple intercompany sale.
-
Multi-Currency Needs Both Transaction Accuracy and Reporting Discipline
Commodity traders may negotiate in USD while local entities keep books in AED, MGA, XOF, INR, or another local currency. Business Central supports transaction currencies on operational documents and a local currency (LCY) for each company. A company can also use an additional reporting currency (ACY) so G/L entries are recorded in a second reporting currency. ACY is useful for parallel reporting, but it should not be treated as the mechanism for translating foreign subsidiaries during group consolidation. Consolidation uses its own business-unit exchange-rate setup.
The practical control is rate governance. In Business Central, dated rates are maintained on the Currency Exchange Rates page, where finance can review the starting date, exchange-rate amount, relational exchange-rate amount, adjustment rates, and whether the rate can be changed on documents. Business Central can also use an external Currency Exchange Rate Service. The service setup defines the provider and service URL, maps incoming fields to the exchange-rate table, and can be enabled for automated updates. This gives finance a visible place to govern both the rates themselves and the connection used to refresh them.
Figure 2. Currency Exchange Rates page in Dynamics 365 Business Central. The JPY values are illustrative; the same page is used to maintain dated rates for USD, AED, MGA, XOF, and other configured currencies. Source: Dynamics 365 Lab.
-
Consolidation Must Show the Group – Not Double-Count the Group
One of the most important finance requirements in a multi-entity commodity group is avoiding double-counting during consolidation. A regional entity may record a sale to headquarters while headquarters records the matching purchase. Both are valid in the standalone books, but the group cannot present both as external revenue and external purchases. Otherwise, consolidated turnover and cost are artificially inflated.
Business Central supports a dedicated consolidation company that brings together general-ledger data from multiple business units, including entities with different currencies and, when mapped correctly, different charts of accounts. If a business unit uses a different currency from the consolidated company, consolidation exchange-rate methods are configured separately; Business Central supports average, closing, and historical-rate approaches depending on the G/L account. The Consolidated Trial Balance can then show business-unit totals, eliminations, and the consolidated result.
For a commodities group, the chart-of-accounts and intercompany design should make eliminations easy to identify and reconcile. Eliminations are a controlled consolidation step, not simply an automatic consequence of enabling intercompany functionality. Finance can enter elimination entries in the consolidated company and use the G/L Consolidation Eliminations report to review the tentative impact before posting. The objective is simple: local management sees the true standalone performance of each entity; group management sees the external economics of the group without duplicated internal revenue or cost.
-
Multi-Country Compliance Is Not a One-Click Global Setting
A common expectation in a multi-country ERP program is that the system will automatically know every local VAT rate, statutory change, and e-invoicing requirement. That assumption needs to be tested country by country.
Business Central has country/region local functionality and can integrate with e-document or government platforms, but requirements differ by jurisdiction. A UAE e-invoicing design, for example, should not be assumed to cover an African or Asian jurisdiction automatically. Each country should be assessed for Microsoft localization coverage, tax setup, statutory reporting, e-invoicing requirements, and any certified third-party provider or API integration.
Implementation Principle
Use one global Business Central operating model where possible, but validate statutory localization country by country. Standardize the core; localize the compliance edge.
-
Banking and Reconciliation Should Reduce Manual Finance Work
Vendor bank details, statement imports, reconciliation, and payment export files are also relevant to commodity traders. Business Central can support bank-account reconciliation, imported bank statements, and payment-file scenarios depending on country, bank, and setup. Business Central online can also provide Copilot-assisted bank reconciliation where the capability is enabled and supported; Copilot supplements automatic matching and proposes matches for transactions that remain unreconciled.
For a trading business with high-value cross-border payments, controls matter as much as automation. Payment approval, bank-master governance, segregation of duties, and the boundary between ERP-generated payment files and final bank authorization should be explicitly designed.
-
The Trade-Document Pack Is a High-Value Automation Opportunity
Another high-value requirement in commodity operations often sits outside the accounting conversation: the trade-document pack. Many traders still maintain linked Excel templates for commercial invoices, packing lists, product details, certificates, and other shipping documents.
That workflow is a strong candidate for Business Central report layouts or a focused extension. The goal should be to use the same transaction data – customer, item, quantity, rate, origin, packaging, shipment references, and any configured commodity-specific fields such as moisture or quality – to generate the full document pack. This removes duplicate typing and reduces the risk that the commercial invoice says one thing while the packing list or certificate says another.
What Should Stay Standard – and What Deserves Design or Extension?
Strong Standard / Configuration Fit
- Companies, customers, vendors, items, locations, and dimensions
- Multiple units of measure and inventory costing
- Purchase/sales orders and invoices
- Multi-currency posting and reporting
- Intercompany partners, account/dimension mapping, and document exchange
- Financial consolidation and elimination workflow
- Bank reconciliation and standard analytics / Power BI
Validate, Localize, or Extend
- Country-specific tax, statutory reporting, and e-invoicing connectors
- Commodity-specific quality fields, assay/moisture data, or bespoke grades
- Commercial invoice / packing list / certificate document packs
- Complex intercompany advances, loans, shared-cost recovery, and settlement logic
- Container, shipment, inspection, or logistics processes beyond standard inventory/warehouse needs
- Specialist commodity risk requirements such as position, hedging, or mark-to-market if required
The Takeaway: Design Business Central Around the Trading Lifecycle, Not Around the Chart of Accounts
The practical conclusion is not that Business Central has a long list of features. It is that the platform can provide a coherent operational and financial backbone for a mid-market commodity trader when the design follows the real lifecycle of a trade: source the commodity, capture the deal, move it between entities, absorb landed costs, sell in the right unit and currency, settle the cash, generate the shipping documents, and report margin locally and at group level.
For organizations evaluating Business Central, the best proof-of-concept is therefore not a generic ERP walkthrough. It is a small number of complete commodity-trading scenarios using your own units, currencies, entities, document formats, intercompany flows, landed-cost rules, and consolidation requirements. If those scenarios work end to end, the software discussion becomes much more meaningful.
Brightpoint Infotech
If you are evaluating Dynamics 365 Business Central for a trading or distribution group, Brightpoint Infotech can help structure a scenario-led discovery and demo around your actual multi-entity, multi-currency, inventory, intercompany, reporting, and compliance requirements.