A trading account is not an Acumatica module — it is a reporting convention, inherited from UK/Commonwealth-style bookkeeping, that most East African finance teams still expect to see. It sits above the profit and loss statement and isolates gross profit from trading activity: opening stock, purchases, direct costs like freight-in and customs duty, and closing stock, set against sales. For a Rwanda-registered trading or import business, getting this right matters for two reasons — RRA wants books that can substantiate gross margin, particularly on imports subject to customs valuation checks, and management wants a clean split between gross margin and operating overhead. Acumatica does not ship a "Trading Account" screen. You build it from Chart of Accounts structure and a Financial Statement or Pivot report design.
What a trading account actually shows
The mechanics are simple: Opening Stock + Purchases + Direct Expenses − Closing Stock gives Cost of Sales. Sales minus Cost of Sales gives Gross Profit. That Gross Profit figure then rolls into the full P&L, where selling, admin, and finance costs are deducted to reach Net Profit. The reason this survives as a reporting layer, rather than just being buried inside COGS, is that Rwandan trading companies — importers of hardware, consumer goods, construction materials — are frequently asked by banks, auditors, and RRA to show gross margin separately from operating expense ratios. A single P&L that blends COGS with rent and salaries into one undifferentiated expense block does not answer that question cleanly.
Chart of accounts and sub-account segmentation
The cleanest way to isolate trading-account line items in Acumatica is with a sub-account segment, not a parallel set of natural accounts. Keep one Sales account, one Purchases/COGS account, one Freight-In account — but tag every trading-related transaction with a sub-account value (for example a "TRADE" segment) distinct from operating-expense sub-accounts ("ADMIN", "SELL", "FIN"). This keeps the natural account structure sane for tax reporting while giving the Financial Statement Designer a clean axis to subtotal on.
Sub-account segment: TRADE-OPS (2 segments, 4 chars each)
Segment 1 - Activity Segment 2 - Cost Type
TRD Trading account STK Opening/closing stock
OPS Operating (below GP) PUR Purchases
FRT Freight-in / duty
SLS Sales
Example postings:
5000-TRD-PUR Purchases - Trading (debit)
5010-TRD-FRT Freight-in & customs duty (debit)
1300-TRD-STK Inventory - Trading stock (asset)
4000-TRD-SLS Sales - Trading (credit)
6100-OPS-ADM Admin salaries (below Gross Profit line)
6200-OPS-SEL Selling & distribution (below Gross Profit line)
Building the trading account in the Financial Statement Designer
With the sub-account segment in place, the Financial Statement Designer (or a Pivot Report against GL Transaction Details) does the rest. Build the report with two blocks: a Trading Account block that subtotals Sales less Cost of Sales (Opening Stock + Purchases + Direct Expenses − Closing Stock) into a Gross Profit line, followed by an Operating block that deducts admin, selling, and finance costs to reach Net Profit. Filter both blocks on the same TRD/OPS sub-account segment so the report self-documents which accounts belong where — auditors and RRA officers reviewing the statement can trace every figure back to a posting rule instead of a manual spreadsheet adjustment.
Closing stock is the one figure that will not come from a GL account balance directly — it comes from the Inventory subledger (Item Costing / Inventory Summary), valued at the period-end date. Reconcile that number against the Trading Account's closing stock line before you publish the statement; a mismatch here is the most common reason gross profit figures get challenged.
Multi-currency purchases and RWF reporting
Most Rwandan trading businesses buy from suppliers in USD or EUR while their statutory books are kept in RWF. That means the Purchases and Freight-In lines in the trading account are exposed to exchange rate movement between invoice date and payment date, and again at period-end revaluation. Set up Currency Rate Types in Acumatica to distinguish the rate used for initial recognition from the rate used for period-end revaluation, and run the revaluation process before closing the period the trading account report covers. If you skip revaluation, the Purchases figure in the trading account will not reconcile to the AP subledger in RWF, and the gross margin percentage you report will drift from what actually happened economically.
Rwanda's EBM (Electronic Billing Machine) requirement means every VAT-registered sale gets a fiscal signature and QR code transmitted to RRA in near-real-time. It is tempting to treat EBM compliance and the trading account as separate concerns, but the Sales figure feeding the trading account must tie back to the same invoice population reported through EBM. Build the Generic Inquiry that feeds your trading account Sales line off the same AR document set used for EBM submission, not a different summary table — otherwise you end up explaining two different revenue numbers to RRA.
Sample trading account layout
A simplified version of what the Financial Statement should render, in RWF, for a monthly or quarterly close:
| Line | Amount (RWF) |
|---|---|
| Sales | 145,000,000 |
| Less: Sales Returns | (2,100,000) |
| Opening Stock | 18,400,000 |
| Add: Purchases | 92,600,000 |
| Add: Direct Expenses (freight-in, duty) | 6,300,000 |
| Less: Closing Stock | (21,900,000) |
| Cost of Sales | 95,400,000 |
| Gross Profit | 47,500,000 |
Gross Profit then carries forward as the opening line of the full P&L, where operating expense sub-accounts (ADM, SEL, FIN) are deducted to arrive at Net Profit. Keeping this as a distinct block, rather than one long undifferentiated expense list, is what makes the statement useful to a bank loan officer or an RRA auditor at a glance.
Closing checklist
Before you sign off a period: confirm the closing stock value from Inventory Summary matches the trading account's closing stock line, confirm currency revaluation ran before the Purchases figure was pulled, confirm the Sales line matches the EBM-submitted invoice population, and confirm no operating-expense transaction accidentally posted to a TRD sub-account (a common data-entry slip that quietly inflates gross margin). None of this requires custom code — it is Chart of Accounts discipline plus one well-built Financial Statement or Pivot report, checked the same way every close.
That is the setup I use for trading account reporting on Acumatica implementations across the region — the same pattern holds whether the business is in Nairobi, Johannesburg, Kigali, Lusaka or Harare, with the sub-account segment and revaluation cadence being the only things that shift per country. If you are stuck wiring this up for your own chart of accounts, reach out or browse the rest of the Acumatica blog.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.