Contact Info
Trading
What does an ERP consultant for trading companies do?
An ERP consultant for trading companies maps how goods are bought, shipped, cleared, costed and sold, then designs an ERP that handles imports, exports, landed cost and multiple currencies without spreadsheets on the side. I document the trade cycle, test platforms against real shipments and guide implementation, so margins are based on true cost and every shipment can be traced from order to payment.
Last reviewed by Vikas Saroj
A trading business makes money in the gap between what goods cost to land and what they sell for. That gap is easy to get wrong when purchase prices are in one currency, freight and duty arrive weeks later on separate invoices, and sales are booked before the final cost is known.
As an independent ERP consultant for trading companies, I start with the trade cycle itself: supplier order, shipment, customs clearance, receipt, sale and settlement. I map where cost, currency and documents change hands, then design an ERP that captures each step once, so margin per shipment and per item is visible without a reconciliation exercise at month end.
Business first, technology second. If the shipment process is unclear, no ERP will fix it.
What I Do
Most trading companies come to me after outgrowing an accounting package and a set of spreadsheets that track shipments, costs and currency gains by hand.
I map the full import and export flow, including proformas, advance payments, letters of credit, shipment documents and clearance, and mark where data is re-entered or lost between teams.
I define which charges belong in item cost, how each is allocated, and how late-arriving freight and clearing invoices are trued up, then make sure the chosen ERP supports that design.
Purchase, sales and reporting currencies, exchange rate sources, realized and unrealized gains and losses, and foreign-currency bank accounts, agreed with your accountant before configuration starts.
Container, bill of lading, vessel and expected arrival captured against purchase orders, so buyers and sales teams can see stock in transit and promise it to customers with confidence.
I test shortlisted ERPs against your real shipments: a mixed container, a split receipt, a late freight invoice and a sale in a third currency, not a vendor's tidy demo script.
I work alongside your implementation partner or internal team to keep configuration aligned with the agreed design, run UAT on real trade scenarios and support go-live.
What to Measure
An ERP for trading should make these numbers available without a spreadsheet. I design the data model and reports around them from the start.
Platform Fit
How I Work
How goods and money move
Supplier and customer workshops
Shipment and clearance flow
Currency and payment terms
Current cost and margin method
Requirements, fit-gap and selection
Trading requirements and BRD
Landed cost and FX rules
Scenario-based platform tests
Fit-gap and resolution plan
Implementation, UAT and go-live
Partner and vendor coordination
Open shipment migration
UAT on real trades
Post go-live margin review
Every trading ERP project I run starts by writing down the trade cycle in plain words, because that sequence becomes the backbone of the requirements. A typical import-led flow looks like this:
Supplier quotation -> purchase order -> proforma and advance payment or letter of credit -> shipment booking -> bill of lading and shipping documents -> customs clearance -> goods receipt -> landed cost finalization -> sales order -> delivery -> customer invoice -> collection -> currency settlement.
Export-led and re-export businesses reverse parts of that flow and add their own documents: commercial invoice, packing list, certificate of origin and export declaration. Back-to-back traders, who buy only against a confirmed customer order, need the purchase and sale linked from the start so margin is known per deal. Drop-ship and indent trades never touch the warehouse at all.
Most trading companies run a mix of these. The process map shows which variants exist, how often each one happens and which team owns each step. That matters because an ERP that handles the common import flow well can still struggle with back-to-back or drop-ship trades, and those are often the highest-margin deals. I capture each variant in process maps before any platform is discussed.
The problems I see in trading businesses are remarkably consistent, whatever the product or market:
None of these are software problems first. They are process and costing decisions that the software has to enforce. I cover the mechanics of landed cost allocation and credit control in more depth in ERP for trading and distribution; on this page the focus is how I help you decide and design.
A trading ERP does not need every module a platform offers. It needs a small set done very well and connected tightly:
| Module | What it must do for a trader |
|---|---|
| Purchasing | Supplier price lists in foreign currency, proformas, advance payments, partial receipts against one order |
| Shipment or import tracking | Container, bill of lading, expected arrival and document status linked to purchase orders |
| Landed cost | Charges attached to a shipment and allocated to items, with a true-up for late invoices |
| Inventory | Stock by warehouse plus stock in transit, batch or serial tracking where needed |
| Sales | Quotations and orders in customer currency, margin visible from landed cost |
| Accounting | Multi-currency ledgers, realized and unrealized FX, foreign-currency bank reconciliation |
| Reporting | Margin per shipment, item, customer and deal |
Shipment tracking is the module most often missing as standard. Some platforms handle it through landed cost documents, others need a light custom object or an add-on. Whether that gap is worth closing with configuration, a small customization or a process change is a question for a proper fit-gap analysis, not a sales demo. For a structured multi-currency view, see ERP for multi-currency operations.
Before configuration starts, I make sure these decisions are written down and signed off by the people who own them:
During testing I build UAT scripts around real shipments, including the awkward ones: a container with mixed items, a split receipt across two warehouses, a freight invoice that arrives after half the goods are sold, and a sale invoiced in a third currency. If the system handles those correctly, the routine trades will look after themselves.
Trading companies typically connect the ERP to banks for statement import, to freight forwarders or shipment visibility tools, to customs or e-invoicing systems where local rules require it, and to a CRM if the sales team works there. I plan these as part of the design, with a named owner and a clear direction of data flow, through ERP integration planning.
For migration, the critical items are open purchase orders, shipments in transit with their costs to date, open foreign-currency payables and receivables at the right rates, and opening stock at landed cost. Years of closed shipments rarely need to move. The trading company ERPNext migration shows how one business moved from spreadsheets and an aging accounting package without losing control of shipments in progress.
On platform choice, Zoho, Odoo, ERPNext and Microsoft Dynamics 365 Business Central can all run a trading business, but they differ in landed cost depth, multi-currency handling and how much shipment tracking needs to be built. The fit table on this page summarizes my view, and best ERP for trading compares them in more detail. If you distribute through routes and van sales rather than import, see ERP for distribution; if you sell in volume to trade customers, see ERP for wholesale.
Tell me about your business and current systems. I’ll suggest the most sensible first step.
Book a Consultation
Not sure which ERP you need?
Share your business requirements with me and I will help you understand the right process, architecture and platform before implementation.
FAQ
Trading companies live on the margin between landed cost and selling price, often across several currencies. The ERP must link purchases to shipments, capitalize freight and duty into item cost, handle exchange differences correctly and show margin per shipment or deal. General ERP setups often treat those as afterthoughts.
Most mid-market ERPs can, but the setup varies. The key is linking the purchase order to the customer order so margin is calculated per deal, and making sure drop-ship orders never create phantom stock. I test both flows explicitly during evaluation rather than assuming they work.
There are two common approaches: estimate landed cost at receipt and true it up when the actual invoices arrive, or hold costing open until all charges are in. Each has accounting consequences, so I agree the method with your finance team and accountant, then confirm the chosen ERP supports it.
Not always, but an independent consultant helps when the trade cycle is complex or the partner is proposing heavy customization. I document requirements, test the platform against your real shipments and review the partner's design, so the system fits your trade rather than the partner's template.
Yes. I work remotely with trading businesses in many markets, through online workshops, shared process maps and structured requirement sessions. Local tax, customs and e-invoicing requirements are captured as part of the requirements and confirmed with your accountant or local advisors.
Every business is different. Share where you are today and what you want to fix, and I’ll tell you honestly whether and how I can help.
Book a Consultation
Insights
Book a Consultation
Book a consultation to talk through your processes, systems and goals. I’ll reply with practical next steps - no obligation.
