Infor CloudSuite Financials Global Ledger Architecture: The Finance Enterprise Group Decisions You Cannot Easily Reverse

Most of the pain practitioners feel in Infor CloudSuite Financials traces back to a handful of choices made on the day the Finance Enterprise Group was created. The Global Ledger is forgiving about transactions and unforgiving about structure. Infor describes the Global Ledger as a single, complete record of financial activity governed by centralized accounting rules, and that centralization is exactly why the foundational objects are hard to change once they hold data. The setup form itself warns that some core information cannot be altered after you save it, which means the accounting string, the core ledger, and the dimension model you commit to are effectively permanent for the life of that group.

This article walks the architecture in the order it actually gets built, from the Finance Enterprise Group down through the accounting string, reporting basis, calendars, currency, and inter-entity balancing. The goal is to flag the precedence rules and the irreversible decisions before they harden into rework.

The Finance Enterprise Group as the accounting backbone

The Finance Enterprise Group, commonly shortened to FEG, defines the entire accounting structure that every accounting entity beneath it inherits. You build it under Application Administration, in Financials, Global Ledger, Setup, Finance Enterprise Groups, and the first thing you name is the core ledger. The core ledger is the spine of the model: it holds every transaction that appears in financial reports, regardless of which reporting basis you later view the data through. Nothing posts outside it.

The decision that quietly determines a lot of downstream flexibility is how many Finance Enterprise Groups you create. For most organizations a single FEG is enough, and Infor’s planning guidance treats one group as the default rather than the exception. The reason to resist splitting into multiple groups is that almost nothing crosses the boundary. As the Infor guidance on planning finance enterprise groups makes clear, financial information is not shared across groups, actors are linked to exactly one group, and vendor and customer records cannot be shared between groups either. If you separate two divisions into two FEGs, you have also separated their consolidated reporting, their security setup, and their master data, and you have committed to maintaining all of that twice. The test worth applying is whether the two populations of accounting entities genuinely share no chart or dimension definitions and never need to be combined for reporting. If they do need to be combined, they belong in one group.

The architectural weight of this choice is why it pays to settle the FEG model during design rather than during build. Teams that approach it with a disciplined Infor implementation framework tend to model the legal entity structure, the reporting obligations, and the consolidation requirements before anyone opens the setup form, because the form does not let you walk most of it back.

The accounting string and where each element lives

The accounting string, sometimes called the code block, is the ordered set of elements that every posting must satisfy. You define it on the Finance Structure section of the FEG, and for each element you set its position in the string and whether it is required.

The Accounting Entity is the legal entity where a transaction posts, and it is the one element you cannot make optional. You can relabel it, for example to Company, and you can change where it sits in the string, but its required flag is fixed. The Accounting Unit is the next structural element, and it behaves differently from how many people expect: it is optional at the FEG level, but the moment you include it, it becomes required, and its structures only exist in the context of an entity. You do not build one global accounting unit tree. You build accounting unit structures when you create each accounting entity, which means the department or cost-center hierarchy can differ entity by entity while still sharing the same string position. Practitioners frequently relabel this element to Department to match how the business actually talks about it.

Below those sit the user dimensions. The FEG supports up to ten user dimensions, each of which you can mark required or optional and place anywhere in the string order. A labeled dimension surfaces its own tab in the interface, so if you label Dimension 1 as Funding Source, a Funding Source tab appears, and you are then responsible for building the dimension structures that populate it. This is where the unlimited dimension flexibility that Infor markets becomes a discipline problem rather than a capability problem. Every dimension you turn on is a value that someone has to supply or default on every transaction that requires it, so the question is never whether you can add a dimension, but whether the reporting payoff justifies the data-entry obligation across every feeder system. Modeling that tradeoff well is part of optimizing efficiency across a CloudSuite deployment rather than just switching capabilities on.

Two further mechanics matter here. Relabeling is global: if you rename a predefined element, the new label replaces the original everywhere in the solution, so the label you pick is the label your whole user base lives with. And validation can be enforced structurally. The FEG provides a Regular Expression tab where you can attach a standard Java regular expression to any dimension defined on the Finance Structure, which lets you enforce format rules on dimension values at entry instead of discovering malformed codes later in reporting.

Structure relations and unit control

Valid combinations of the string are governed by structure relations rather than left open. The Unit Control setting on the Options tab determines the level at which unit balancing is enforced, with valid values of Account, Accounting Unit, or Dimension 1. When you choose Accounting Unit or Dimension 1, a structure relation must exist between the account and that element, and the unit behavior is maintained on the Structure Relation Pair Detail record. The relation detail can carry its own value, and if you leave it on Default, the system falls back to the value set on the account itself. This is the precedence rule to remember when a transaction unexpectedly requires, or unexpectedly permits, a unit value: the relation detail wins unless it is set to Default, in which case the account-level setting applies.

The core ledger and the reporting basis model

The piece that gives CloudSuite Financials its multi-GAAP capability is the separation between the core ledger and the reporting basis. The core ledger captures everything once. A reporting basis is then a defined combination of structures, a ledger together with a chart of accounts and a calendar, that produces a particular view of that data. Because you can define more than one reporting basis over the same underlying transactions, you can present the same activity under different accounting treatments, different account groupings, and different period calendars without re-posting anything. Infor positions this as unlimited ledgers and basis reporting, and in practice it is how a single set of postings serves statutory, management, and tax views at the same time.

The reporting basis is also the unit of work for several processes that practitioners assume run at the entity level. Currency revaluation and translation, for instance, are processed by reporting basis, not entity by entity, so the composition of a basis directly affects what a revaluation run touches. Budgeting is similar: a reporting basis can be flagged as a budget basis and set for budget edit, and the encumbrance behavior is controlled through the Encumbrance option in the relevant Global Ledger system codes, with Track and TrackAndEdit as the meaningful settings for organizations that need encumbrance control. If you run public-sector or grant-funded accounting, the budget basis and its encumbrance option are not afterthoughts; they are part of the basis design from the start.

Because reporting basis records drive the analytics layer as well, the structures you include determine what the dashboards can slice. The Birst-powered analytics embedded in Financials read against the reporting basis, so a dimension you omitted from a basis is a dimension your users cannot pivot on in that basis. This is another reason the dimension and basis design deserve to be settled together rather than sequentially.

Calendars, currency, and revaluation behavior

Calendars in CloudSuite Financials are not limited to a single fiscal pattern. You can create a monthly calendar at FEG creation and add others afterward, which is what lets organizations run different fiscal year ends, funding year ends, and reporting periods against the same transactions. Each calendar carries a close configuration that defines the period closing dates, and that close configuration is what the reporting basis and the accounting entities reference when they close a period. The practical consequence is that period close is governed by configuration, not by a single hard-coded calendar, so a funding calendar and a fiscal calendar can close on different schedules without conflict.

Currency is set on its own tab, where you select up to five enterprise currencies that the accounting entities in the group can use. The Default Decimals option deserves attention because of a subtle behavior: it controls how many decimals are allowed when a transaction is created, but the decimals defined on the currency code itself apply when the transaction is saved. If the default option is two and the currency code allows three, a value entered with two decimals is stored with three on save, which can surprise anyone reconciling entered values against stored values. You also set an auto balance threshold per currency, which caps how much the system will auto-balance when a journal is released manually, and if you enable currency revaluation and translation you must designate the gain and loss accounts the process posts to.

Some accounts are not optional at all. The Undistributed Retained Earnings and Retained Earnings accounts and the Error Suspense account are always required system accounts. Zone payables and receivables become required only if you use zone balancing, the currency gain and loss accounts become required only when you enable translation and revaluation, and the inter-entity payables and receivables accounts become required only when you create inter-entity transactions. Knowing which system accounts are conditionally required keeps the setup from stalling on accounts you do not actually need yet.

Inter-entity balancing and intercompany design

When a single journal carries lines for more than one accounting entity, the ledger has to balance each entity independently, and the FEG controls how. The Inter Entity Dimension setting determines whether sub-accounts or one of the ten dimensions carries the system-generated balancing lines, and those balancing lines are identifiable by their event code in the inter-entity journal entry. This is the mechanism behind clean intercompany postings: rather than forcing users to balance each entity by hand, the system generates the offsetting lines using the dimension you nominated. Designing this well means deciding early which dimension or sub-account scheme represents the inter-entity relationship, because changing it after entries exist is exactly the kind of structural change the platform resists.

Inter-entity design also reaches outward. The FEG can trigger a Business Object Document when the group changes, and BOD-based messaging is how Financials participates in the wider Infor estate. Organizations that move accounting and master data between applications through ION-based integration using BODs need the BOD trigger and the BOD cost center dimension set correctly on the Options tab, or the outbound messages will not carry the cost center context downstream systems expect.

Where Project Ledger changes the rules

If you license Project Ledger, the Project element joins the accounting string, and it changes several behaviors. Project is generally optional and is used on expense-type transactions, but if you mark it required it must appear on every qualifying transaction. The Project Ledger capabilities Infor describes depend on options set at the FEG level, not just at the project level. Date validation is one example: the Project Date Edit setting decides whether transactions are validated against the project date range using the transaction date, which suits service billing by rate, or the posting date, which suits period-based control. Burden calculation is another, where the project burden date determines which rate applies when indirect costs are generated.

Funding adds a hard dependency. If you enable Project Invoicing on the Options tab to bill external customers or grants, Finance Dimension 2 becomes required and is used to hold the funding sources, the customers and grantors behind each project. Until you create that dimension structure in the FEG, the project funding menus do not even appear, which is a common source of confusion for teams that expect to configure funding before the dimension exists. Project reporting bases work the same way as financial reporting bases but typically use a simplified project chart that excludes accounts such as undistributed retained earnings, which keeps project reports focused on the accounts that matter for commitments, encumbrances, and actuals.

Planning the decisions you cannot easily reverse

The throughline across all of this is sequence and permanence. The accounting string, the core ledger identity, and the dimension model are set at FEG creation and are difficult or impossible to change once transactions exist. Master data, security actors, and customer and vendor records are bounded by the FEG and do not cross into other groups. Reporting bases, calendars, and currencies offer real flexibility, but only over the structures the FEG already exposes. The work that prevents rework is front-loaded into design, and it is the same work that makes a later data migration into these accounting structures predictable rather than improvised, because the targets are stable before the data arrives.

Practitioners who treat the Finance Enterprise Group as an architecture rather than a setup screen end up with a ledger that absorbs new entities, new GAAP views, and new dimensions without structural surgery. That is the payoff, and it is available only to teams that decide the irreversible things deliberately. Organizations weighing those decisions often bring in Infor CloudSuite consulting and support at the design stage precisely because the cost of getting the FEG wrong is paid for years afterward.

Frequently asked questions

Can you change the accounting string after the Finance Enterprise Group is saved?

Only partially. The finance enterprise group setup explicitly states that some core information cannot be changed after you save it, and the accounting string is among the structural choices that are effectively permanent once data exists. You can relabel elements and add dimension values within the existing model, but you cannot freely reorder or remove core elements after the group is in use, which is why the string is a design decision rather than a configuration you iterate on.

Should we use one Finance Enterprise Group or several?

For most organizations a single group is the right answer. Infor’s planning guidance for finance enterprise groups notes that financial information, actors, and vendor and customer master data are all bounded by the group and do not cross between groups. Splitting into multiple groups duplicates master data and security and breaks shared consolidation, so it is justified only when two populations of entities genuinely share no chart or dimension definitions and never need combined reporting.

How does the core ledger differ from a reporting basis?

The core ledger holds every transaction that appears in financial reports, regardless of basis, so it is the single record of activity. A reporting basis is a combination of a ledger, a chart of accounts, and a calendar that produces one view of that activity. The separation is what delivers the unlimited ledgers and basis reporting that let the same postings serve statutory, management, and tax views without re-posting.

Why did my currency revaluation run touch entities I did not expect?

Because revaluation and translation are processed by reporting basis rather than entity by entity. The composition of the basis determines the scope of the run, so a basis that mixes entities with and without currency activity will process all of them. Reviewing which entities a basis contains before running revaluation is the way to control what the process touches.

What controls whether an accounting unit value is required on a transaction?

Unit Control on the Options tab sets the enforcement level, and the actual requirement is resolved on the Structure Relation Pair Detail record. If the relation detail is left on Default, the value set on the account applies; otherwise the relation detail value wins. That precedence is the usual explanation when a unit value is required or permitted in a way the account-level setting alone would not predict.

How is intercompany balancing generated within a single journal?

When a journal has lines for multiple accounting entities, the system generates balancing lines so each entity nets to zero. The Inter Entity Dimension setting decides whether sub-accounts or one of the ten dimensions carries those generated lines, which are identifiable by their event code in the inter-entity journal. The inter-entity payables and receivables system accounts must exist for this to post, but they are required only if you actually create inter-entity transactions.

What has to be in place before Project Ledger funding will work?

If you turn on Project Invoicing to bill external customers or grants, Finance Dimension 2 becomes required and holds the funding sources. The project funding menus do not appear until that dimension structure is created in the finance enterprise group, so the dimension has to exist before the funding configuration is visible. The broader Project Ledger functionality also depends on FEG-level options such as the project date edit and burden date settings.

Which system accounts are mandatory at setup?

Undistributed Retained Earnings, Retained Earnings, and Error Suspense are always required. The currency gain and loss accounts are required only when you enable revaluation and translation, zone payables and receivables only when you use zone balancing, and inter-entity payables and receivables only when you create inter-entity transactions. Treating the conditional accounts as conditional keeps setup from blocking on accounts the deployment does not yet need.