This conversation happens regularly in the mid-market: a CFO invests in a NetSuite or Sage Intacct implementation, the go-live is declared a success, and six months later the controller is managing the close in the same Excel tracker they were using before, now with the added complexity of reconciling ERP output to manually maintained spreadsheets. The ERP did not make the close worse — but it did not make it meaningfully better, either.
The reason is structural: ERPs are transaction recording systems. Their core design objective is ensuring that debits equal credits, that transactions are properly coded to the chart of accounts, and that the audit trail is intact. That is a different problem from close management — and understanding the gap is the prerequisite for filling it intelligently.
What ERPs Do Well (and Were Built to Do)
Modern mid-market ERPs — NetSuite, Sage Intacct, Microsoft Dynamics 365 Business Central — handle the following close-adjacent tasks with reasonable competence when properly configured:
Period-end journal entry posting. Once a standard JE template is built, the ERP can post it reliably. Period locks prevent back-dating. The audit trail is automatic. This is a genuine ERP strength.
FX revaluation for foreign currency balances. Most mid-market ERPs have automated revaluation runs that apply the period-end exchange rate to open foreign currency balances and book the unrealized gain or loss. The calculation itself is reliable — though the configuration of which accounts are in-scope for revaluation requires a one-time setup investment, and the controller still needs to review the revaluation output for reasonableness.
Report generation. Trial balances, income statements, balance sheets — the ERP generates these accurately once the GL data is complete. The output is correct, assuming the inputs are correct.
That last clause — "assuming the inputs are correct" — is exactly where the ERP's competence ends and the close management problem begins.
The JE Matrix Problem
A typical mid-market month-end close involves 30–80 journal entries across recurring standard postings, period-specific accruals, reclassifications, and intercompany eliminations. ERPs do not have a native concept of a JE matrix — a structured view of which JEs are required each period, who is responsible for each, which have been posted, and which are overdue.
What most teams end up with: a spreadsheet listing the required JEs, manually checked off as each one posts. The controller or senior accountant cross-references the ERP's JE log against the spreadsheet to confirm completeness. This works until someone adds a new recurring JE, forgets to update the spreadsheet, and the JE gets missed two months running before the reconciliation catches it.
The ERP's JE log is a comprehensive transaction record — it shows every JE that was posted. It is not a control list of JEs that should have been posted. That distinction is the gap. A close management system maintains the expected JE set; the ERP records the actuals; the control comparison happens in the middle layer.
Intercompany Elimination: Where ERPs Frequently Fall Short
Intercompany elimination is consistently the most ERP-dependent and most ERP-incomplete piece of the close for multi-entity mid-market companies. Here is the specific failure pattern:
Each entity books its half of an intercompany transaction independently — Entity A records an intercompany receivable; Entity B records the contra payable. When both sides match, elimination is straightforward. When they do not match — because one entity used a different period date, a different FX rate, or a different account code — the elimination cannot be completed cleanly until the discrepancy is identified and resolved.
Most mid-market ERPs handle same-instance intercompany (multiple subsidiaries on a single NetSuite account) reasonably well with native intercompany matching rules. Where they break down is cross-instance intercompany — two entities on different ERP systems, or two NetSuite accounts that have not been configured for automated matching. The matching and reconciliation process falls out of the ERP and into a spreadsheet, and the eliminations become a manual Day 1 or Day 2 task with a significant risk of error if the volume is high.
This is not a criticism of any specific ERP vendor. It is a description of what ERPs were designed for: accurate recording within an instance. Cross-entity coordination is fundamentally a workflow and communication problem that sits between ERP instances, not within one.
FX Revaluation: The Configuration Gap
FX revaluation automation in ERPs handles the arithmetic correctly. The gap is in the control layer around it. Specifically:
The revaluation report needs to be reviewed for material items before the JE posts. A large unrealized FX gain or loss on an intercompany balance might be correct — or it might indicate that an intercompany payment was made in the wrong currency, or that a cash account is in the wrong currency field. The ERP will calculate and post whatever it finds; it does not have a materiality threshold or a review gate.
The close management layer adds: a threshold review step (flag revaluation items above $X for controller review before posting), a connection between the revaluation JE and the underlying account reconciliation (so the reviewer can see both in context), and a sign-off record that the revaluation output was reviewed and approved.
PBC Binder Integration: The Missing Link
The ERP does not know what your external auditors call a PBC — the prepared-by-client package of reconciliations, JE support, and methodology documentation. That package exists entirely outside the ERP: in a shared drive, in email threads, in a combination of ERP-generated reports and Excel workpapers.
The result: at year-end, when the external auditors arrive and issue the PBC list, your team spends two to three days assembling documents from multiple sources into a format the audit team can navigate. Some reconciliations are in NetSuite's account reconciliation module. Some are in Excel on a shared drive. The JE support is a mix of ERP-generated reports and manually attached PDFs. Locating and presenting all of it to the auditors takes time the team does not have at year-end.
This is not a criticism of the ERP — it is simply outside what ERPs were designed to do. The ERP stores transactions. The PBC binder stores the interpretation, support, and review documentation around those transactions. Bridging those two is a workflow problem that the close management layer addresses by maintaining a structured, auditor-navigable documentation library as a byproduct of the monthly close process, not as a separate annual exercise.
What to Actually Expect From Your ERP
We are not saying that ERPs are inadequate for finance teams. We are saying that expecting an ERP to manage the close workflow — task assignment, review routing, JE completeness control, PBC organization — is like expecting a general ledger to run accounts payable. It is not a failure of the ERP; it is a scope mismatch.
The right framing: the ERP is the system of record for financial transactions. The close management layer is the operating system for the close process. They are complementary, not competitive. The ERP data flows into the close management layer through a direct GL sync; the close management layer provides the workflow, review controls, and documentation structure that the ERP was never designed to provide.
Controllers who have tried to make their ERP do both jobs have discovered the limitation empirically. The finance team at a growing regional healthcare services organization — 4 entities, 3 currencies, about 350 GL accounts — spent several months trying to run their entire close inside NetSuite after a full implementation. The transaction recording was clean. The close management was still Excel and email. The reason was consistent with every other case: NetSuite recorded what happened. It could not tell them what was supposed to happen and whether it had.
That is the gap. Filling it does not require replacing your ERP — it requires giving your close team the workflow layer that sits in front of it.