Geneva is one of the world's leading hubs for commodity trading: metals, energy, agricultural products, ores. Companies established here buy and resell goods that, very often, never touch Swiss soil. This economic reality is poorly served by general-purpose ERPs designed for distributors who buy, store and deliver locally. AX-Fiduciaire is established in Geneva, at the heart of this ecosystem, and configures Odoo to meet the real constraints of trading rather than those of standard commerce.
This page describes what an Odoo deployment involves for a trading company, what the tool covers correctly, and where its limits lie. For accounting configuration as such, see our Odoo accounting page; for managing physical flows, see inventory and purchasing.
What sets trading apart from standard distribution
A distributor buys stock, receives it physically, stores it in a warehouse it controls, then resells it to its own customers. Margin is calculated on a relatively linear flow: purchase price, holding costs, sale price. A standard ERP, configured for this pattern, works well.
Trading operates differently on several structural points:
- Goods can be bought and resold without ever entering a warehouse belonging to the Swiss company — they move between the original seller and the final buyer, with the trading company only involved in the ownership and documentation chain.
- Transactions are denominated in different currencies on each side (purchase in USD, sale in EUR, for example), with a currency risk to hedge or absorb.
- Transport, insurance and the transfer of ownership follow contractual rules (Incoterms) that don't necessarily coincide with the physical movement of the goods.
- A significant share of transactions is financed through specific instruments — letters of credit, bank pre-financing — that structure the timeline and payment terms.
- Profitability is managed deal by deal, not at the level of an aggregated monthly turnover.
An Odoo configuration that ignores these particularities produces accounting that is formally correct but unreadable for steering the business. The challenge of the project is therefore not installing Odoo, but configuring it around the deal-based logic specific to trading.
Deal-by-deal tracking: the central building block
In a trading company, the relevant management unit is neither the customer nor the product, but the deal: a linked purchase and sale, with their associated costs, forming together a transaction whose exact margin needs to be known.
In Odoo, this logic is built via analytical accounting: each deal is attached to a dedicated analytic account or project. Purchase, sale, freight, insurance, brokerage and financing entries linked to that deal are then posted against the same analytic axis. It then becomes possible to extract, for a given deal, all the income and costs that make it up, and therefore its actual margin — regardless of the accounting period in which the various invoices fall.
This configuration is decided upstream of the project: the structure of analytic accounts, automatic allocation rules from purchase and sale orders, templates for recurring costs (freight, insurance, brokerage) to be spread across the relevant deals. This is a matter of setup, not a feature that switches on with one click.
Multi-currency: a native constraint, not an option
Trading is inherently multi-currency: purchase in USD, sale in EUR, costs billed in CHF or GBP depending on the service provider. Odoo natively handles foreign currency accounts, recording documents in their original currency, and converting to CHF at the rate applicable on the transaction date. Three points deserve particular attention during configuration:
- The source of exchange rates — automatic via a rate service, or manual entry depending on the company's policy, with traceability of the rate used for each document.
- Exchange differences — unrealised (on open currency positions) or realised (on settlement), which must be identified and posted separately from the deal's commercial margin.
- Periodic revaluation of foreign currency accounts at closing, to present CHF financial statements that correctly reflect currency exposure at the balance sheet date.
Odoo doesn't hedge currency risk: it records and values positions, but the decision to hedge a currency risk (forward, option) and its operational tracking remain outside the scope of the ERP.
Flows without storage in Switzerland
A significant share of Geneva trading operations never sees the goods pass through Switzerland: purchase from a supplier in one country, resale to a buyer in another, with the Swiss company involved in the contractual and documentary chain, not in local physical logistics. For these flows, the inventory configuration in Odoo must be designed differently from a standard warehouse:
- Transit or non-Swiss type locations can be created to represent goods in transit or stored with a third party, without implying any physical presence in Switzerland.
- When a warehouse abroad is genuinely used (buffer storage, bonded warehouse, free zone), it can be modelled as a separate Odoo location, with its own valuation rules — but the customs and tax regime applicable to that warehouse depends on the country concerned and must be validated upstream, independently of the Odoo configuration itself.
- The transfer of ownership, which can occur at a different moment from the physical movement (depending on the Incoterm used), must be reflected in the posting of the purchase and sale, not just in the stock movement.
Commercial documentation: Incoterms and supporting documents
Each trading transaction relies on a set of documents that, together, prove the transfer of ownership, the actual transport and the terms of sale: contract, bill of lading or transport document, certificate of origin, packing list, insurance policy, commercial invoice.
Odoo doesn't replace these commercial documents and doesn't manage Incoterms as a strictly structured field — but it does allow you to:
- Attach supporting documents (scans, PDFs) directly to the relevant deal or order, for a centralised, searchable document file.
- Track delivery and invoicing deadlines associated with each deal.
- Reconcile, via the analytic allocation described above, transport documents and the costs they generate with the corresponding deal.
The Incoterm used (FOB, CIF, DAP, etc.) determines the moment at which risk and ownership change hands, which has a direct impact on the posting date of the sale and on VAT treatment. This is decided contractually, upstream of Odoo data entry, and must be consistent with the accounting configuration chosen for the deal.
VAT: a matter to examine case by case
The VAT treatment of a trading transaction depends directly on the actual path of the goods: do they enter Swiss territory, do they leave it, or do they remain permanently abroad while the trading company is Swiss? These three situations don't call for the same treatment, and the rules vary according to the precise facts of each transaction — place of delivery, Incoterm, customs status of the goods, status of the parties involved.
We don't detail these rules here: they must be examined transaction by transaction, supported by the contractual and transport documents. Odoo automatically installs the Swiss localisation (l10n_ch module) once the company is configured in Switzerland, which lays a correct VAT calculation base for local flows, but doesn't remove the need for case-by-case analysis for the international flows typical of trading. For the general principles of Swiss VAT, see our Swiss VAT page.
Margin steering and financial reporting
Once deal-by-deal tracking and multi-currency are correctly configured, Odoo allows reporting to be produced that reconciles margin by deal, consolidated margin by period, and open currency exposure. Odoo's standard analytic reports (result by analytic account, budget comparison) cover a good part of this need; additional dashboards can be built to provide a view by deal, by counterparty or by type of commodity, according to the company's management priorities.
This reporting remains dependent on the quality of upstream data entry: a deal poorly attached analytically, or a cost posted on the wrong axis, distorts the result of the deal concerned without this being immediately visible in the overall totals. This is why initial configuration and entry discipline matter more, in this context, than in standard distribution accounting.
What Odoo covers well, and its honest limits
Odoo, properly configured, covers well:
- General and analytical accounting, with native Swiss localisation.
- Deal-by-deal tracking via analytic axes.
- Multi-currency for purchasing, selling and settlement.
- Basic document management (attachments linked to deals).
- Stock tracking, including locations representing flows outside Switzerland.
However, Odoo is not a specialised CTRM (Commodity Trading and Risk Management) tool. It doesn't natively offer:
- Real-time market position management and associated risk calculation (VaR, mark-to-market).
- Systematic hedging on derivative instruments linked to commodities.
- Detailed management of letters of credit and the documentary conditions of trade finance.
- Automated reconciliation of very large volumes of physical contracts with paper positions.
For a company whose trading volume and complexity justify active market risk management, a dedicated CTRM remains necessary, with an accounting interface to Odoo rather than full management within the ERP. For a trading company whose activity mainly rests on documented physical transactions, with more conventional financing, a properly configured Odoo covers most management and accounting needs, at a significantly lower total cost of ownership than a specialised CTRM. The choice between the two depends on the actual profile of the business, not a matter of principle.
AX-Fiduciaire's role
AX-Fiduciaire is a Geneva accounting firm and Odoo partner. On a trading project, our involvement covers three strands:
- Accounting and analytic configuration — account structure, analytic axes by deal, automatic allocation rules, currency and exchange difference management. See Odoo accounting.
- Swiss compliance — l10n_ch localisation, consistency of the chart of accounts with Swiss law, alignment with VAT obligations specific to international trading (see Swiss VAT).
- Fiduciary support — bookkeeping, closings, filings, beyond the technical configuration alone, as part of our ongoing Geneva accounting practice.
The deployment follows the same methodology as any Odoo project: scoping the company's actual flows, defining the analytic architecture, configuration, testing on real deals before go-live. See our Odoo implementation page for the details of the approach, and our Odoo in Geneva page for the local context. AX-Fiduciaire is based at Boulevard Georges-Favon 26, in Geneva.