How to choose an accounting ERP for a trading business

Most ERP evaluations focus on the feature list. For a trading company, the feature list is rarely where things go wrong — it's the assumptions baked into the data model. Here's what's actually worth checking before you sign anything.

1. Is your customer/supplier list a real ledger, or a lookup table?

Many systems keep "Customers" and "Suppliers" as separate tables from the chart of accounts, then reconcile them into the ledger behind the scenes. That works fine until you need a party who is both — common in trading, where today's supplier is next month's customer on a different deal. Ask whether the party master is the ledger account, or whether it's a separate list that gets mapped to one. The former avoids an entire category of reconciliation bugs.

2. Does "multi-branch" mean separate databases, or a filtered view?

Two systems can both claim "multi-branch support" and mean very different things. Some filter one shared database by a BranchID column — fast to set up, but a single bad query or permission bug can leak one branch's data into another's report. Others provision genuinely separate scoping per branch or company. If you're running branches across two countries with different statutory requirements, ask specifically how isolation is enforced, not just whether it's "supported."

3. How is tax logic actually structured?

"We support VAT and GST" is a marketing sentence. The real question: is tax logic set once at the company level, or independently at the branch level? A trading company with a UAE and an India branch needs the latter — different rates, different filing calendars, different document rules, all coexisting inside one company's consolidated reports.

4. What happens when you need a module you didn't buy at first?

Trading companies grow in stages — core ledger first, then inventory once warehousing gets complicated, then POS if a retail counter opens, then payroll once headcount justifies it. Ask whether adding a module later is a genuine incremental step, or effectively a re-implementation. Systems that provision schema per module can add Inventory Control in week one and Banking in month six without touching what's already live; systems built as one monolithic schema often can't do this cleanly.

5. Who can edit and delete a posted transaction — and is there a record of it?

A shockingly common pattern in older trading-company software: a single shared "delete password" known to two or three senior staff. It works, until it doesn't — there's no way to know who actually used it or why. Look for role-based permissions (who can edit, who can delete, per module) combined with an automatic audit log on every insert, update and delete. This matters more at audit time than almost any other feature on the list.

6. Does the vendor understand your industry, or your feature list?

Generic accounting software (built for retail, services, or single-country SMEs) can usually be configured to handle trading — eventually, with enough customization. Software built specifically around a trading company's structure — chart-of-account party masters, sales/purchase order to delivery challan to GRN flows, credit/debit notes tied to statutory requirements — tends to need far less bending to fit.