Working with Nextera on a SunSystems engagement
A SunSystems engagement is not a software installation with some configuration attached. It is a redesign of how your finance function records, controls and reports — delivered in a system. That framing matters, because it explains where these projects actually stall: on decisions only the customer can make.
This page is written for whoever is sponsoring the engagement on the customer side.
What only you can decide
Section titled “What only you can decide”Nextera brings the product knowledge and the implementation method. These remain yours, and an engagement waiting on any of them is an engagement not moving:
- The chart of accounts design principle. Specifically, the discipline that the account code answers “what kind of value is this?” and everything else lives in dimensions. Overloaded account codes are the near-universal mistake, and only you can refuse to make it.
- Which analysis dimensions you need. Derived from the reports and regulatory returns you must produce — not from what feels tidy. Get this list from your obligations, backwards.
- Which dimensions are mandatory on which account types. Enforcing at entry is trivial; fixing unallocatable costs at close is not.
- Your close calendar and its sequence, including who signs off each step.
- Allocation policy — what is allocated, on what driver, and at what point in the close. This is usually the most contested design conversation, and it is a management decision rather than a technical one.
- Your consolidation basis and intercompany identification approach. Every intercompany balance must be identifiable at posting time; reconstructing it at close does not scale.
- What is summarised versus detailed on each interface from a subsystem. Traceability versus ledger volume, decided deliberately per interface.
- Every regulatory return you must file, in full, at the start. A return that surfaces in month five is a dimension-structure change, and dimension-structure changes late in an implementation are expensive.
What to prepare before the first workshop
Section titled “What to prepare before the first workshop”| Artefact | Why it matters |
|---|---|
| Current chart of accounts, with usage volumes per account | Shows what is actually used versus what merely exists |
| Current close calendar, with actual — not target — durations | The design has to fit the real close |
| Every regulatory return you file, with its source | These drive the dimension structure |
| The spreadsheets that currently bridge gaps | The single most informative artefact in the room |
| Your management reporting pack | What the business actually reads |
| Interface inventory — every system that feeds or consumes the GL | Integration scope |
| Organisation and entity structure, with ownership percentages | Consolidation |
| Known pain points, stated plainly | Prevents rebuilding the current problems in a new system |
The spreadsheet row is not a joke. Every workaround spreadsheet marks a requirement the current system does not meet, and collectively they are a more accurate requirements document than any requirements document. Bring them, including the embarrassing ones.
What the engagement asks of your team
Section titled “What the engagement asks of your team”Finance-system implementations fail on customer availability more often than on anything technical. Be honest about this at the start rather than discovering it in month three:
- A finance decision-maker who can settle design questions in the room. Not someone who takes them away — someone who decides.
- Process owners for each area — general ledger, purchasing, sales, fixed assets — who know how the work is actually done, including the exceptions.
- A data owner for migration. Data cleansing is customer work; it cannot be outsourced, because only you know which of two similar records is the real one.
- Testing capacity. User acceptance testing is done by your users, and it needs to be in their objectives rather than added on top of a close.
- An IT contact for each interface.
The single most common cause of delay is a design question raised in week three and answered in week nine. Naming a decision-maker up front is the cheapest risk mitigation available.
Where the risks actually are
Section titled “Where the risks actually are”- Data migration. Almost always larger than estimated, because opening balances have to reconcile exactly and historical data is rarely as clean as everyone believes.
- Late regulatory requirements. A return that surfaces after the dimension design is set.
- Customisation creep. Each customisation carries a cost at every upgrade. Each one should be a deliberate decision with a written reason, not a default response to “that’s not how we do it”.
- The first year-end, not go-live. Consolidation, translation, statutory reporting and the audit all exercise paths a monthly close never touches. Plan support around it.
- Knowledge transfer. If your team cannot operate the system independently at the end of post-go-live support, the engagement has not finished regardless of what the plan says.
How this connects to your other systems
Section titled “How this connects to your other systems”SunSystems sits at the centre of the finance landscape, and several Nextera products sit around it:
- Nextera Accord computes lease journals under PSAK 116 / IFRS 16 and hands them to the general ledger.
- Nextera Guard holds the ICoFR control library. Your close checklist and your control library describe the same activities — ideally as the same records rather than as two lists that drift apart.
- Nextera Bright produces reinsurance technical accounting that reaches the ledger through an interface.