Finance system concepts
Konten ini belum tersedia dalam bahasa Anda.
Infor SunSystems is a financial management system: general ledger, purchasing, sales, and the reporting built on top. A SunSystems implementation is mostly a series of design decisions about the structures below, so understanding them is the difference between participating in the design and receiving it.
The chart of accounts, and the mistake it usually contains
Section titled “The chart of accounts, and the mistake it usually contains”The chart of accounts (COA) is the list of accounts every transaction is posted to. It determines what you can report on, and it is expensive to change once history exists.
The near-universal mistake in a first design is overloading account codes. When the COA has to answer “which account, which department, which product, which branch, which project” all in one code, it grows to thousands of accounts, becomes unmaintainable, and still cannot answer a question nobody anticipated.
The correct instinct is the opposite: the account code answers “what kind of value is this?” and nothing else. Everything else is a dimension.
Analysis dimensions
Section titled “Analysis dimensions”Dimensions are the separate axes attached to each posting: cost centre, department, branch, product line, project, channel, entity, and so on. SunSystems is well known for this model, and using it properly is the single highest-leverage decision in the implementation.
The design questions that matter:
- Which dimensions do we need? Derive them from the reports and regulatory returns you must produce, not from what feels tidy.
- Which are mandatory, on which account types? A cost account without a cost centre is an unallocatable cost, and it is far easier to enforce at entry than to fix at close.
- What is the value list for each, and who maintains it?
- What is the hierarchy within each dimension? Branch rolls into region rolls into country — this is what makes reporting aggregate correctly without a mapping table.
- What happens when the structure changes? Reorganisations happen. Whether history is restated or preserved is a policy decision, and it should be made before the first reorganisation rather than during it.
For an insurer, the dimensions almost always include line of business and legal entity, because both statutory and regulatory reporting are demanded along those axes.
Ledgers, journals and postings
Section titled “Ledgers, journals and postings”A journal is a balanced set of postings — debits equal credits — recorded together with a date, a source and a description. The general ledger is the accumulation of all of them.
Concepts that shape the design:
- Journal types / sources distinguish where entries come from: manual, accruals, recurring, revaluation, and interfaces from subsystems. Being able to identify a posting’s source is a control, not a convenience.
- Posting versus provisional. Provisional (unposted) entries let you model an impact before committing it. What may remain provisional at close is a policy decision.
- Reversing entries for accruals — created and automatically reversed in the next period.
- Recurring journals for predictable entries.
- Allocations — spreading a cost across dimensions on a defined basis. Deciding what is allocated, on what driver, and at what point in the close, is one of the more contested design conversations.
Subledger to general ledger is the other structural relationship: purchasing, sales, fixed assets, payroll and — in insurance — policy administration, claims and reinsurance systems all produce entries that reach the GL. For each interface, four things must be agreed: what is summarised versus detailed, how frequently it runs, how it is reconciled, and what happens to a rejected entry.
Systems such as Nextera Accord sit in exactly this position: they compute lease journals and hand them to the GL.
Multi-currency
Section titled “Multi-currency”Any Indonesian financial institution with foreign business needs three currency concepts distinguished:
| Currency | Meaning |
|---|---|
| Transaction currency | What the transaction actually happened in |
| Functional / base currency | The primary economic environment’s currency — normally IDR |
| Reporting currency | What the statements are presented in, which may differ for a group |
The associated design decisions: where rates come from and how often they load; which rate type applies where (spot, average, closing); how revaluation of monetary balances is run and where the gain or loss posts; and how translation differences on consolidation are handled.
Getting the rate type by transaction type right is the detail that most often surfaces late, usually as an unexplained variance.
Period close
Section titled “Period close”The close is the recurring heartbeat of the system, and a well-designed one is a defined, ordered, evidenced sequence rather than a set of habits.
A typical order: subledger cut-off → interfaces run and reconciled → accruals and provisions → allocations → intercompany reconciliation → revaluation → review → period lock → reporting.
Design decisions worth settling early: how many periods may be open at once; who can reopen a closed period, and how that is evidenced; and what soft close versus hard close means in your organisation.
Everything here is also an ICoFR control. If you use Nextera Guard, the close checklist and the control library should describe the same activities — and ideally be the same records.
Consolidation
Section titled “Consolidation”Consolidation combines entities into group statements. Its requirements shape the ledger design more than anything except the COA:
- A consistent COA across entities, or a maintained mapping between local charts and the group chart. The mapping is where most consolidation errors originate.
- Intercompany identification and elimination. Every intercompany balance must be identifiable at posting time — normally by a trading-partner dimension — because reconstructing it at close does not scale.
- Translation of foreign entities into the reporting currency, with the resulting differences handled correctly.
- Ownership percentages and minority interests where entities are not wholly owned.
What “audit-ready” concretely means
Section titled “What “audit-ready” concretely means”The phrase is used loosely. In practice it comes down to five properties, all of which are design decisions rather than afterthoughts:
- Traceability. Any figure in a report can be drilled to the transactions behind it, and each transaction identifies its source.
- Immutability. Posted entries are not edited; corrections are made by further postings, so the history is complete.
- Attribution. Who entered, who approved, and when — retained.
- Segregation of duties. The person who creates a payment is not the person who approves it, enforced by the system rather than by convention.
- Reconciliation evidence. Subledger-to-GL and bank reconciliations produced, reviewed and retained on a defined cycle.
For an Indonesian insurer or financial institution there is a sixth, practical property: the reporting structures must produce the regulatory returns natively. Reports assembled in spreadsheets from ledger extracts are the single most common cause of both audit findings and late filings — and they are a design failure in the dimension structure, not a spreadsheet problem.
How these concepts map to the SunSystems engagement
Section titled “How these concepts map to the SunSystems engagement”| Concept on this page | Engagement phase |
|---|---|
| Understanding how finance actually runs today, and what must be reported | Requirement Analysis |
| COA, dimensions, journal types, currency and close design, built in the system | Configuration & Customization |
| Close calendar, allocations, controls and consolidation aligned to the organisation | Financial Process Alignment |
| Traceability, immutability, attribution, and native regulatory returns | Regulatory & Audit Readiness |
| Subledger interfaces, insurance platforms, and everything around the GL | System Integration |
| Keeping the design correct as the business changes | Post-Go-Live Support |