SunSystems implementation phases
A SunSystems engagement runs through six phases. They overlap in practice — integration design starts during requirement analysis, and regulatory readiness informs the chart of accounts rather than following it — but each produces something distinct.
If any term here is unfamiliar, read Finance system concepts first.
1. Requirement analysis
Section titled “1. Requirement analysis”Understand how finance actually runs before configuring anything, from chart of accounts to reporting.
What it addresses. How the finance function actually operates today — not how the policy manual says it does. The transaction flows, the close calendar, the reports that get produced and the reports that get produced and then rebuilt in Excel, the regulatory returns, and the judgements people make that are currently held in someone’s head.
Why it comes first. Every structural decision downstream — chart of accounts, dimensions, journal types, close sequence — is derived from what has to be reported and how work actually flows. Configuring before this is understood produces a system that is technically correct and operationally wrong.
What to prepare. Your current chart of accounts, your close calendar, a list of every regulatory return you file, and honest examples of the spreadsheets that currently bridge the gaps. The spreadsheets are the most informative artefact in the room, because each one marks a requirement the current system does not meet.
2. Configuration & customization
Section titled “2. Configuration & customization”Configure SunSystems to those requirements, customising where the standard product needs to flex.
What it addresses. Building the design: chart of accounts, analysis dimensions and their hierarchies, journal types and sources, currency configuration and rate types, allocation rules, security and approval structures, and the reporting layer.
The decision that matters most. Keeping the account code answering “what kind of value is this?” and pushing everything else into dimensions. Overloaded account codes are the near-universal mistake in a first design, and they are expensive to unwind once history exists.
Configuration versus customisation. Configuration is what the product supports natively; customisation is code or extension beyond it. Customisation is legitimate where the standard product genuinely does not flex, and it carries an ongoing cost at every upgrade — so each instance should be a deliberate decision with a stated reason, not a default response to “that’s not how we do it”.
3. Financial process alignment
Section titled “3. Financial process alignment”Align consolidation, reporting and controls to how the organisation operates.
What it addresses. The processes running on top of the configuration: the close calendar and its sequence, allocation and accrual routines, intercompany identification and elimination, consolidation, and the controls around all of it.
Why it is separate from configuration. Configuration decides what the system can do; alignment decides what the organisation will do, in what order, and who signs it off. Two organisations with identical configuration can run very different closes.
Where it connects. Everything in this phase is also an ICoFR control. If you run Nextera Guard, the close checklist and the control library should describe the same activities — ideally the same records rather than two lists that drift apart.
4. Regulatory & audit readiness
Section titled “4. Regulatory & audit readiness”Set up reporting structures that stand up to Indonesian regulatory and audit requirements.
What it addresses. Making the required returns and the audit trail fall out of the system natively rather than being assembled afterwards.
What “audit-ready” concretely requires. Traceability from any reported figure to the transactions behind it; immutability of posted entries, with corrections made by further postings; attribution of who entered and who approved; segregation of duties enforced by the system; and reconciliation evidence produced, reviewed and retained on a cycle.
The Indonesian-specific part. Regulatory returns must be produced from the ledger structure. Reports assembled in spreadsheets from ledger extracts are the most common cause of both audit findings and late filings — and that is a dimension-design failure, not a spreadsheet problem, which is why this phase feeds back into phase 2.
5. System integration
Section titled “5. System integration”Connect SunSystems to the core insurance and operational platforms around it.
What it addresses. The interfaces: policy administration, claims, reinsurance, billing and collections, payroll, fixed assets, banking, and specialist systems such as Nextera Accord for lease journals.
Four things to agree per interface. What is summarised versus detailed; how frequently it runs; how it is reconciled; and what happens to a rejected entry. The last one is the question most often left until it happens in production.
Why summarisation is a real decision. Posting every policy transaction individually gives maximum traceability and a ledger that becomes unusable. Posting monthly summaries gives a clean ledger and pushes traceability back into the source system. Neither is wrong; the choice must be deliberate and it must be documented, because an auditor will ask.
6. Post-go-live support
Section titled “6. Post-go-live support”Stay on after go-live to keep the system stable as the business changes.
What it addresses. The period after cutover, when the design meets reality: the first close on the new system, the issues that only surface at quarter and year end, and the knowledge transfer that determines whether your team can operate it independently.
Why it is a phase rather than an afterthought. A finance system’s design assumptions decay as the business changes — new entities, new products, reorganisations, new regulatory requirements. Each of those touches the chart of accounts or the dimension structure, and each is far cheaper to handle correctly than to correct later.
What to watch for. The first year-end is the real test, not go-live. Consolidation, translation, statutory reporting and the audit all exercise paths that a monthly close never touches.