Every ERP is a transaction engine first and a reporting tool second. This leaf is about the second job — turning the general ledger, costing, work-in-progress and inventory valuation that already sit in SYSPRO, ERPNext, Sage or Oracle into statements people can act on. It stays deliberately ERP-agnostic, then shows where an open BI stack — Evidence and friends — earns its place alongside ERPNext.
Financial reporting is the discipline of turning raw accounting transactions into statements that answer a question: are we making money, where, and is it real? The general ledger, sub-ledgers, costing, work-in-progress and inventory valuation are the inputs. Income statement, balance sheet, cash flow, and the management pack are the outputs.
The ERP owns the inputs. It is the system of record for every journal, every costed transaction, every stock movement. What it is usually weaker at is the output layer — flexible, reproducible, multi-entity reporting that a finance team can shape without a consultant. That gap is the subject of this leaf, and it's the same gap whether the ERP underneath is SYSPRO, ERPNext, Sage X3 or Oracle.
2nth never re-keys financial truth. Reporting reads from the ERP (or a warehouse fed by it), assembles and narrates, and writes nothing back into the ledger. The double-entry and period-close semantics live in the ERP for good reasons — the reporting layer consumes them, it doesn't override them.
Manufacturing and distribution ERPs differ in their APIs and their depth, but the reporting feed is remarkably consistent. These are the objects every financial report is assembled from — and costing, WIP and inventory valuation are exactly where an ERP like SYSPRO is strongest.
| ERP input | What it holds | What it feeds |
|---|---|---|
| General ledger | Every posted journal, by account and period | Income statement, balance sheet, trial balance |
| AR / AP sub-ledgers | Customer and supplier balances, ageing | Working capital, cash-flow forecasting, DSO/DPO |
| Costing | Standard / actual cost, variances by job | Gross margin, cost-of-sales analysis, pricing |
| Work in progress | Value of open production orders | Inventory on the balance sheet, margin timing |
| Inventory valuation | Stock on hand at cost (FIFO / weighted / standard) | Balance-sheet stock, obsolescence, GP integrity |
Getting these out is an API exercise, and it's the part that varies. ERPNext exposes every doctype as REST. SYSPRO offers REST plus the deeper e.net layer. Sage X3 is GraphQL over Syracuse; Oracle Fusion is REST. The shape differs; the five inputs don't. Read the per-ERP leaves under biz/erp for the exact mechanics.
Most reporting failures come from treating these as one job. They have different consumers, cadences, and tolerances for being slightly wrong.
| Dimension | Statutory | Management |
|---|---|---|
| Audience | SARS, CIPC, auditors, lenders, shareholders | Owners, exco, ops and finance leads |
| Standard | IFRS / IFRS for SMEs, fixed format | Whatever drives the decision |
| Cadence | Annual (plus tax filings) | Monthly, often weekly flash |
| Tolerance | Must reconcile to the cent; audited | Directionally right and fast beats late and perfect |
| Best tool | ERP close + accountant + audit | A flexible reporting layer on ERP data |
The ERP's native close handles statutory well. It's the management column — the monthly pack, the margin-by-product cut, the multi-entity roll-up — where teams hit the wall of canned ERP reports and start exporting to spreadsheets that nobody can reproduce next month. That's the opening for a proper BI layer.
ERPNext is the best-positioned ERP for this move: open-source, API-first, every doctype a REST resource, no licence wall around your own data. That makes it cheap to pull the reporting feed into a warehouse and build a code-first reporting layer on top — version-controlled, reproducible, and free of the spreadsheet graveyard.
The stack is four small steps, each swappable and each open-source:
Evidence is the part worth knowing. It's open-source BI-as-code: you write SQL queries and markdown, and it renders a fast, static reporting site with charts and tables. Reports live in Git, so a management pack is reviewable, diff-able, and reproducible — the same inputs always produce the same P&L. No dragging pivot tables; no "which version is current?".
<!-- pages/management.md — an Evidence report page --> /* Query the warehouse table built from ERPNext GL + costing */ ```sql gross_margin select month, revenue, cogs, revenue - cogs as gross_profit, round(100.0*(revenue-cogs)/revenue, 1) as gp_pct from fct_income_statement order by month ``` # Management accounts — gross margin Gross profit is tracking at {gross_margin[gross_margin.length-1].gp_pct}% this month. <LineChart data={gross_margin} x=month y=gross_profit/> <DataTable data={gross_margin}/>
Where it fits next to dashboard tools. Metabase and Superset are great for self-serve dashboards finance staff click around in. Evidence is for the narrative, repeatable artefact — the board pack, the monthly management accounts, the lender report — where you want prose, version history, and a number that is always derived the same way. Many shops run both: dashboards for exploration, Evidence for the documents that get signed.
A proprietary ERP makes you fight for clean data egress — SYSPRO is reachable but deployment-dependent; Oracle and Sage gate it behind their own tooling. ERPNext hands you every figure over REST with no per-seat reporting licence, which is what makes a self-owned warehouse-plus-Evidence layer cheap enough to be worth it for a mid-sized business. The open ERP and the open BI stack are the same bet: own your data and your reporting, end to end.
Reporting is high-leverage for AI assistance and high-stakes for AI autonomy. The useful pattern keeps the agent on the assembly and narrative, never on the sign-off.
Pull the period's GL, run the close checklist, flag accounts that didn't reconcile or moved more than a threshold versus prior month. The agent surfaces; the accountant resolves.
Draft the commentary — "gross margin down 2.1pts on input-cost inflation in raw materials" — straight from the warehouse marts. Finance edits the words; the numbers come from SQL, not the model.
Bank vs ledger, sub-ledger vs control account, inter-company mismatches. The agent is a tireless first-pass reviewer that never gets bored on line 4,000.
The model does not invent a number, post a journal, or approve a statement. Every figure traces to an ERP transaction or a SQL transform a human can re-run. Statutory output stays auditor-grade.
| Reach for the warehouse + Evidence when | Stick with native ERP reports when |
|---|---|
| Multiple entities or sources to consolidate | One company, one ledger, simple structure |
| You need reproducible, version-controlled packs | A monthly export to a spreadsheet genuinely suffices |
| Management reporting outgrew canned ERP reports | The ERP's standard reports already answer the questions |
| You're on ERPNext (clean, free data egress) | Data egress is hard or licensed and the ROI isn't there yet |
The honest line: don't stand up a warehouse to produce one P&L. The stack pays off when reporting is multi-source, repeated monthly, and needs to be defensible. Below that, the ERP's own reports plus an accountant are the right amount of machinery.
Statutory reporting here runs on IFRS or IFRS for SMEs, with annual financial statements and CIPC annual returns. Tax filing is its own rhythm — VAT201, EMP201, and provisional tax all pull from the same ledger and have to tie back to it. B-BBEE reporting adds spend and ownership cuts that the management layer can produce cheaply once the data is in a warehouse.
Two local realities shape the build: forex (multi-currency revaluation if you import inputs or export goods, priced in ZAR but exposed to the dollar), and the firm line that assurance stays human — an agent can assemble and narrate, but a registered auditor signs. None of that changes the architecture; it just sets the guardrails.
Reporting sits downstream of every ERP leaf and upstream of the data layer that does the heavy lifting.
The open BI tools named above, and the ERP accounting docs the feed comes from.