Infor LN Multi-Site Deployment Architecture: Distributed Database Topology, Inter-Company Transactions, and Data Synchronization

Multi-site Infor LN deployments fail for a predictable set of reasons. The enterprise structure is modelled without a clear understanding of how the database layer maps to the organisational layer. Intercompany transaction setup is deferred until post-go-live. Data sharing decisions are made on the fly rather than governed by a coherent data architecture decision tree. The result is a system that runs technically but produces unreliable financials, misaligned intercompany postings, and master data inconsistencies that compound over time.

This post is written for Infor LN architects, ERP technical leads, and senior implementation consultants responsible for designing and deploying multi-site LN environments. We will cover the full architecture: how LN structures its database in a multi-company deployment, the three data synchronisation mechanisms and when each is appropriate, the intercompany transaction engine and its relationship to the financial posting model, and the design decisions that determine whether a multi-site deployment is maintainable over a five-year horizon.

Understanding LN’s Multi-Site Mental Model Before Touching Configuration

Before any session is opened, any company created, or any enterprise unit defined, the implementation team needs to hold a precise understanding of how LN represents a complex organisational structure. The terminology is specific and the relationships between objects are non-obvious.

As documented in Infor’s official User Guide for Multicompany Structures, a multi-site LN environment usually consists of a structure of multiple logistic and financial companies. The two company types serve fundamentally different purposes and exist at different levels in the data architecture.

A logistic company is used to maintain company-wide transactional data, logistic and commercial master data. A single logistic company can span multiple countries and contain multiple plants, warehouses, distribution centres, and sales offices. The logistic company is the organisational container for production orders, purchase orders, sales orders, inventory, routings, and BOM data.

A financial company is restricted to one currency area and exists to conduct accounting and tax reporting for each business unit in each country’s local currency. Financial companies are linked to the logistic company through enterprise units – not directly. A financial company cannot cross currency boundaries, which means that a single logistic company operating in the Eurozone and in the United States must be linked to at least two financial companies.

Enterprise units are the structural bridge between the two layers. An enterprise unit is a financially independent part of the organisation. It consists of entities such as departments, work centres, warehouses, and projects within one logistic company. Every warehouse and every department in the logistic company is linked to an enterprise unit, and that enterprise unit is linked to one financial company. When a logistic transaction is posted – a goods receipt, a sales shipment, a production completion – LN determines which enterprise units are involved in the debit and credit of that transaction, and posts the financial consequences to the corresponding financial companies automatically.

Infor’s multisite overview documentation distinguishes the two parallel organisational dimensions clearly: enterprise units reflect the financial flow, and sites reflect the logistics flow of the business processes of an organisation. Sites group warehouses and departments for production and logistics data governance purposes. Enterprise units group the same warehouses and departments for financial reporting purposes. A single warehouse is simultaneously a member of one site (logistics) and one enterprise unit (financials). This dual membership is what enables LN to produce accurate financial results from logistic transactions without requiring manual financial postings.

The critical design decision that flows from this architecture is stated explicitly in Infor’s own documentation: before you create the enterprise units, you must carefully design the enterprise structure. After you perform transactions based on the structure, changing this data is extremely difficult. This is not a documentation caveat. It is an architectural constraint. Enterprise unit assignments to financial companies, and warehouse-to-enterprise-unit mappings, are embedded in every historical transaction. Restructuring them in a live system requires a level of data migration complexity that is effectively equivalent to a reimplementation.

Part 1: Distributed Database Topology

Single-Server vs. Multi-Server Architecture

Infor LN supports a three-tier architecture consisting of a display tier, an application tier, and a database tier. The database tier is where the multi-site complexity concentrates. In a multi-company LN deployment, the fundamental database architecture decision is whether all companies share a single physical database server or whether different companies exist on different servers.

Per Infor’s technical documentation on multi-company server configurations, companies on a single server can share database tables directly through logical table linking. To share data between companies installed on different servers, you must use the sessions of the Exchange module in LN Tools to exchange and synchronise the database tables. This single distinction – same server or different servers – determines which data sharing mechanisms are available and which data synchronisation overhead applies.

Single-server deployments with multiple companies can use logical table linking for real-time data sharing across companies without any replication latency. Multi-server deployments cannot use logical table linking and must rely on the LN Exchange module or ION-based synchronisation, both of which introduce latency and operational complexity.

For cloud deployments of Infor LN on AWS, as described in Infor LN’s cloud ERP documentation, the platform is delivered as a multi-tenant cloud solution, and the database infrastructure is managed by the platform. The important implication for multi-site architecture is that the data sharing mechanism choices are constrained by the deployment model. Understand the deployment model before designing the data architecture.

How LN Organises the Database

All application data used by LN is stored in database tables in the RDBMS. LN uses a data dictionary that contains domain, schema, and referential integrity information stored in a database-independent manner, as documented in Infor’s Enterprise Server Technical Reference Guide. The LN database driver maintains referential integrity independently of the underlying RDBMS – it does not rely on database-level foreign key constraints. This architecture decision has a significant implication for multi-site data integrity: referential integrity checks happen in the application layer, not the database layer, which means that direct database writes that bypass the application tier can produce referential integrity violations that LN cannot detect until a downstream transaction attempts to process the corrupt data.

In a multi-company structure, LN stores data by company number. A company number is a prefix on every table that segregates the data physically in the database while allowing the application to traverse company boundaries through controlled mechanisms. This company-number-based data segregation is what makes logical table linking architecturally possible: when you define a logical table for company 601 pointing to the physical company 600, LN simply routes all database reads and writes for that table in company 601 to the company 600 table. The access happens in real time because it is a pointer redirection within the same database server, not a data copy.

For multi-server deployments, separate instances of LN on separate database servers cannot use pointer redirection. Data that needs to be consistent across servers must be physically replicated, and replication introduces the consistency challenges that all distributed database systems face: propagation latency, conflict detection, and recovery from failed replication events.

The Three Data Sharing Mechanisms

The choice between the three data sharing mechanisms available in LN multi-site deployments is one of the most consequential decisions in the architecture design phase. The three mechanisms are logical table linking, data replication, and the LN Exchange module. Each serves a distinct use case and carries specific trade-offs.

Logical Table Linking

As described in Infor’s User Guide for Table Sharing, logical table linking means that users from multiple companies use one single physical instance of the data. If the company tables are on the same server, this can be accomplished by logical table linking. Access to the physical data is real time – the moment a record is created or modified in one company, it becomes available in all linked companies as well.

The architectural constraint on logical table linking is that table sharing implies all attributes for a record are exactly the same in all companies. If you share the item table and a particular item in one company has product class XXX, all other companies must have the same product class for that item. This is not a flexible constraint. It means that logical table linking is appropriate for data that genuinely must be identical across all companies – item codes, unit sets, calendars, currency data – and is not appropriate for data where companies need company-specific variants.

The table reference chain creates the most significant design complexity in logical table linking. The item table references item groups, MCS tables, engineering data, bills of material, routings, and cost accounting data. If you share the item table, you are implicitly committing to sharing everything in its reference chain that it touches. Table references must be investigated in detail for each implementation, and the dependency chain must be fully mapped before any logical table linking is configured.

Data Replication

Data replication exists in multiple instances of the same data across multiple physical locations. The update of data must be controlled to ensure consistency. Replication can be carried out by database table, by record, or by column, giving more granular control than logical table linking.

Unlike logical table linking, data replication can be used across different servers, making it the primary mechanism for geographically distributed multi-site deployments where different plants operate on separate LN servers. The replication process introduces latency – the time between when data changes in the source company and when that change is available in the target company. For master data like item records, currency rates, and business partner data, this latency is usually acceptable. For transactional data where real-time consistency is required, replication latency is a design problem.

A critical operational constraint documented by Infor practitioners is that during the replication process, the data must be frozen. For high-volume master data replication events, the freeze window needs to be managed carefully to avoid blocking production use of the replicated data. For a global manufacturer with a shared item master across five geographic sites, a poorly managed replication freeze can block order entry across the entire enterprise during the freeze window.

LN Exchange Module

The LN Exchange module is designed for batch-driven data transfer between LN companies installed on different servers. It is the appropriate mechanism for planned, scheduled data synchronisation of master data between server boundaries where real-time consistency is not required.

The Exchange module uses ASCII file-based transfer as its transport mechanism, with exchange schemes defining the field mappings between source and target tables. The batch-driven nature of Exchange makes it appropriate for nightly synchronisation of price lists, routing updates from an engineering company to production companies, and standard cost updates from a corporate cost accounting company to individual plant companies. It is not appropriate for transaction-level data that needs near-real-time availability across server boundaries.

For that latter requirement – cross-server transactional data synchronisation in near-real time – the ION middleware layer is the current best-practice solution in Infor LN deployments. ION’s event-driven, publish-and-subscribe architecture routes BODs between company contexts asynchronously, with the latency profile depending on message queue depth and ION infrastructure sizing.

Part 2: Enterprise Model Design – Practical Architecture Decisions

The Multisite Concepts Activation Decision

Site-related sessions and fields in LN are available only if the multisite concepts are activated in the Concept Activation session (tcemm4600m000). For any organisation that currently runs LN without sites and plans to add multi-site functionality, a site activation process is required when migrating from an older version. This is a one-way architectural transition – you do not deactivate site functionality after activation.

The decision to activate multisite concepts should be made in conjunction with the enterprise unit design and the site-to-enterprise-unit mapping plan. Activating multisite concepts without having this design complete creates a state where parameter settings that were previously global need to be reassigned to sites and warehouses, a migration process that requires careful data analysis and testing.

Designing the Company Structure

Infor’s LN documentation on multisite company structures identifies the key structural combinations available:

A single logistic company with a single financial company is the simplest structure, appropriate for a single-country operation where all entities share one currency and one legal entity. Financial reporting is central, and intercompany postings occur only when different enterprise units within the same financial company are involved in the same transaction.

A multi-logistic, single-finance structure manages manufacturing and distribution processes in multiple separate logistic companies while performing financial accounting in one company. This structure is appropriate for an organisation with multiple production sites in one country that have their own BOMs and production processes but form one legal entity. The common examples are separate production environments that need operational independence – their own order books, their own production schedules – but consolidated financials.

A multi-logistic, multi-finance structure manages manufacturing and distribution in multiple logistic companies with separate financial accounting for each. This is the structure required by global manufacturers with legal entities in multiple countries, each needing to report in local currency with country-specific tax regulations. A financial company cannot cross currency boundaries, so each legal entity in a different currency area needs its own financial company.

The design warning documented by Infor is explicit: hardware limitations and restricted data replication possibilities can, in some cases, force you to define a separate logistic and financial company for each entity or LN server. The architecture should not be driven by hardware topology. Hardware should be provisioned to support the correct architectural design, not the other way around. This distinction matters because hardware-driven company proliferation creates unnecessary intercompany transaction complexity and data synchronisation overhead that persists for the lifetime of the deployment.

Planning Clusters and Multisite Planning

If Enterprise Planning is implemented, logistics and production planning is based on planning clusters. Sites are grouped by planning cluster within the company. A planning cluster can include multiple sites, and a site can be linked to one planning cluster. This grouping has performance and scheduling implications: all sites within a planning cluster participate in the same central planning run, which means planning data for those sites is processed together. Placing geographically or operationally independent sites in the same planning cluster creates planning run performance overhead and scheduling complexity that can be avoided by correct cluster design.

Part 3: Intercompany Transactions – The Financial Engine

The Trigger Mechanism

As documented in Infor’s official intercompany transactions reference, intercompany transactions are financial transactions that LN automatically creates between financial companies that belong to the same financial group. The transactions are posted to intercompany ledger accounts. LN creates them automatically when you finalise the transactions – you do not need to run any additional sessions.

The trigger is purely structural. When the debit and credit sides of a logistic transaction resolve to different financial companies through the enterprise unit chain, LN automatically generates the intercompany posting. The implementation team’s job is to ensure the Inter-Company Relations setup is correct, not to manage the creation of individual intercompany transactions.

The Inter-Company Relations session (tfgld0515m000) is where you define, for each combination of source company and destination company, the transaction types for which you want to set up intercompany transactions, and the ledger accounts to which the intercompany transactions must be posted. The ledger account types must be of type Intercompany. You also enter the related transaction type used for the posting in the target company.

For multi-currency deployments, the Intercompany Relations by Currency session (tfgld0122m000) extends this to define, for each combination of source company, destination company, and transaction currency, the transaction types and the intercompany ledger accounts. This currency-level configuration is mandatory in standard currency system deployments and is where many multi-currency intercompany implementations contain configuration gaps that produce incorrect postings on cross-currency transactions.

Intercompany vs. Intergroup Transactions

The distinction between intercompany and intergroup transactions is one of the most frequently misunderstood aspects of LN multi-site financials, and getting it wrong produces transactions that appear correct in individual company ledgers but fail to eliminate correctly at group consolidation.

Intercompany transactions are financial transactions LN automatically creates between financial companies that belong to the same financial group. The transactions are posted to intercompany ledger accounts.

Intergroup transactions occur between financial companies that belong to different group companies. They are posted to intercompany ledger accounts but use a different setup configuration than intercompany transactions. For organisations that have multiple distinct corporate groups under a holding structure, or that have acquired new entities that operate as separate financial groups, the intergroup transaction mechanism is the correct one – not intercompany. Configuring intercompany transaction types for a cross-group relationship produces postings that will not eliminate at group consolidation level.

Intercompany Settlement Transactions

Intercompany settlement transactions are a specific subtype that applies only to purchase and sales transactions between logistic companies in a multi-logistic, single-financial company structure. The architectural purpose of intercompany settlement is efficiency: intercompany settlement transactions generate less than half the number of postings – 10 versus 24 – of a regular invoicing procedure. Therefore, if no invoices are required between the entities, intercompany settlement transactions considerably reduce the number of postings in the ledger accounts.

The configuration switch is at the enterprise unit – business partner level: for WIP transfers and inventory transfers, clearing the Intercompany Settlement check box routes the transaction through the standard invoicing path. For organisations that need an internal audit trail of goods movements between sites but do not need formal internal invoices (no transfer pricing complexity, no cross-currency requirement, no internal profit recognition), intercompany settlement substantially reduces posting volume without losing traceability.

In a multi-logistic, single-financial company structure, intercompany settlement transactions are automatically posted, requiring no manual intervention. In a multi-logistic, multi-financial company structure, they are not available – the separate financial entities require full intercompany transaction processing.

Part 4: Intercompany Trade – Transfer Pricing and Internal Order Management

The Intercompany Trade Framework

Intercompany trade (ITR) is LN’s framework for managing the commercial relationships between enterprise units that have their own profit and loss registration processes. As Infor’s official Intercompany Trade documentation states: when a project or an order is created, various entities within an organisation perform activities to execute that order. If the entities have their own P&L registration process, for each activity, internal cost and revenue transactions must be registered to balance the accounts. You can set up intercompany trade to allow LN to create internal cost and revenue transactions and internal invoices.

ITR is distinct from the intercompany financial transaction mechanism described in the previous section. Financial intercompany transactions automatically balance the books when different financial companies are involved in the same logistic transaction. ITR creates the commercial layer on top of that – it defines what price one entity charges another for goods or services transferred between them, and produces the internal invoices that reflect those charges.

Internal Business Partners and Enterprise Unit Relationships

ITR setup begins with defining the entities involved as internal business partners. A one-to-one relationship must exist between an internal business partner and an enterprise unit. For WIP transfers and inventory transfers, this business partner definition is mandatory and the Intercompany Settlement check box must be cleared to route transactions through the ITR invoicing path.

The Enterprise Unit – Enterprise Unit Relationships session (tcemm0134m000) is where you define the default intercompany trade relationships between enterprise units. The relationship category determines how the ITR order is structured – whether it represents an external material delivery scenario, an external material direct delivery, a subcontracting scenario, or a service scenario. Getting the relationship category correct is a prerequisite for the correct ITR order type being generated when the originating logistic order triggers an ITR order.

Transfer Pricing Configuration

Transfer pricing in LN is configured through the Intercompany Trade Agreement and the Transfer Pricing Rules session (tcitr1605m000). This session defines the price origins, priorities, and markup or markdown percentages or amounts for each intercompany trade scenario within an agreement.

Price origins available in LN’s transfer pricing engine include purchase price (the price paid by the purchasing entity to an external supplier), standard cost (the item’s standard cost in the selling entity), sales price (the external selling price of the item), and cost-plus (standard cost or purchase price plus a defined markup percentage). The priority setting among multiple price origins determines which origin LN uses when more than one is available for a given transaction.

Standard costs in a multi-site LN environment can be specified by company or by enterprise unit. If your business units use different standard costs, you must specify the standard cost by enterprise unit and link the warehouses and departments to the enterprise units. This is the correct approach for transfer pricing accuracy: enterprise unit-level standard costs feed the cost-plus pricing calculation for that unit’s shipments, reflecting the actual cost base at that production location rather than a corporate-average standard.

The relationship between transfer pricing and tax country is more complex in LN than most implementations initially account for. The intercompany trade relationship can depend on the tax country, especially when multiple registrations within one financial company are used. Through relationship extensions, a specific agreement can be specified based on the tax countries involved. This is available when Registration by Tax Country is active. The delivery terms and point of title passage on the intercompany trade order determine which tax country applies, and the system can retrieve these from either the internal business partner defaults or from the originating order, controlled by the Default for Delivery Terms and Point of Title Passage parameter in the Intercompany Trade Parameters session (tcitr0100m000).

The ITR Order Transaction Flow

Understanding the transaction lifecycle of an ITR order is essential for diagnosing posting failures in a live multi-site environment.

When a triggering logistic event occurs – a sales order line is processed, a warehouse transfer is confirmed, a subcontracting order is completed – LN checks whether an intercompany trade relationship exists for the entities involved. If a relationship is found, an ITR order is created automatically. The ITR order carries the buying and selling entity information, the price origin calculation result, the invoicing type (internal invoice required or not), and the invoice currency.

For each transaction line on the ITR order, cost and revenue transactions are posted to financials. If internal invoicing is specified, the invoice lines are posted to Invoicing. The status of the invoicing and posting process is visible in the ITR Order Transaction Lines session (tcitr3110m000), with separate status fields for the financial company of the buy-from enterprise unit (Status Buying) and the financial company of the sold-to enterprise unit (Status Selling).

Errors in ITR transaction processing almost always originate from one of three sources: a missing or incomplete intercompany trade relationship for the entity combination involved, a transfer pricing rule that resolves to a zero price because the required standard cost or purchase price master data is missing, or a tax country mismatch that routes the transaction to an incorrect tax registration. Each failure type requires a different diagnostic path and a different resolution.

Part 5: Data Synchronisation – Architecture and Operational Governance

What Must Be Synchronised and Why

The multi-site data synchronisation challenge in LN is not one problem – it is several, and each requires a different architectural response. Breaking it down by data category:

Common master data – items, units, business partners, calendars, currencies – needs to be consistent across all companies in the multicompany structure. LN’s table sharing guide makes this explicit: the companies of a multicompany structure must use consistent data. You can use the same calendars, item codes, business partners, and pricing information in the various sites. Some data must be shared, other data can be shared if required, and still other data must not be shared at all.

The three-category classification is critical. Data that must be shared includes DEM enterprise model data (which must reside in one company and be accessible to all), currency exchange rates shared across financial companies, and the shared item master for companies that process the same items. Data that can be shared includes pricing data, business partner credit limit data, and standard costs – these can be shared or maintained independently depending on the degree of centralisation the organisation wants to achieve. Data that must not be shared includes company-specific financial transactions, production orders, sales orders, and all other operational data that represents the independent activities of each site or company.

Logical Table Linking Design Patterns

For single-server multi-company deployments, the recommended logical table linking pattern follows a hub model: common master data tables are physically stored in one company – the primary or hub company – and logically linked in all other companies. Infor’s documentation for setting up a company shows this explicitly: in a multicompany structure consisting of companies 600, 601, 602, and 603, the tccom000 table and its reference tables are physically stored in company 600. The corresponding logical tables in companies 601, 602, and 603 must all be linked to physical company 600.

The logical table linking setup in the Maintain Logical Tables session (ttaad4120m000) requires converting to runtime after saving – changes are not active until the runtime conversion is executed and the bshell is restarted. This operational detail is important for any maintenance activity that modifies logical table assignments in a production environment.

The choice of physical company for each table is permanent in the sense that historical data always points to the physical company number where the table resides. If you later need to change which company physically holds a shared master data table – for example, because the original primary company needs to be decommissioned – the migration is complex and should be planned from the initial design.

Cross-Server Synchronisation with LN Exchange

For multi-server deployments, the LN Exchange module handles scheduled synchronisation of data that cannot use logical table linking. The exchange scheme defines which tables are transferred, in what direction, at what frequency, and with what field mappings. Exchange schemes are the configuration artefacts that need to be version-controlled and governed with the same rigour as application configuration.

Exchange operates on ASCII file-based transfer. The source company exports data to ASCII files, the target company imports from those files. The file transfer mechanism between servers can be shared filesystem mounts, FTP, or any mechanism that delivers the files to the expected location before the import job runs.

The synchronisation frequency for each exchange scheme should be set based on how rapidly the source data changes and how stale the target data can be before it causes operational problems. Standard cost updates that run once annually can use weekly or monthly exchange jobs. Pricing data that changes monthly needs more frequent synchronisation. Item master changes in an environment where new items are constantly being introduced for new product development activity need near-daily synchronisation to prevent order entry failures caused by missing item data in the receiving company.

ION-Based Master Data Synchronisation

For modern LN deployments on the Infor OS platform, ION’s BOD-based messaging provides an additional synchronisation path that complements the Exchange module. As documented in Infor’s LN Cloud Integration Guide for ION, LN publishes master data changes as BODs – synchronous for some objects, queued for others. The accounting entity and location BODs that uniquely identify each financial company and each warehouse or department in the LN enterprise structure are published through ION and received by subscribing systems.

For multi-site LN environments where different plants operate as separate LN instances connected through ION, BOD-based master data synchronisation provides an event-driven alternative to scheduled Exchange jobs. When an item is created or updated in the master company, LN publishes a SyncItemMaster BOD to ION, which routes it to all subscribed LN instances. The receiving LN instance processes the BOD and creates or updates the item in its local company context.

The ION synchronous versus asynchronous processing decision has a direct impact on transaction processing performance in the originating LN instance. The Synchronous Processing parameter on a BOD implementation determines whether the second independent process triggered by an incoming BOD is started as part of the original transaction or as a separate transaction. For high-volume transaction environments, forcing all triggered processes to be synchronous can create transaction completion latency that affects shop floor responsiveness. Profile the BOD processing load before making synchronous processing decisions for transaction-level BODs.

The General Ledger Balance Publication Constraint

One ION-specific constraint that affects multi-site financial reporting architecture is documented in Infor’s LN Cloud Integration Guide. The Publish General Ledger Balances session (tfbia8211m000) cannot run in parallel with the Finalization Process session (tfgld1212s000). If the GL balance publication session is started when the Finalization Process is running, it waits until the Finalization Process is finished. Conversely, if the Finalization Process is started when the GL balance publication session is running, the Finalization Process waits.

In a multi-company environment where multiple financial companies are finalising transactions simultaneously and GL balances need to be published to an external analytics or reporting platform, this mutual exclusion constraint needs to be accounted for in the job scheduling architecture. Staggering the finalization and publication windows across companies prevents contention and ensures GL balance data reaches the reporting platform within the expected latency window.

Part 6: Common Architecture Failures and How to Avoid Them

Designing the Enterprise Structure for Today’s Organisation, Not Tomorrow’s

Enterprise structure design is expensive to change after transactions are posted. A manufacturing company that today operates as one legal entity but has plans to spin off a division in three years should model that future state in the initial enterprise structure, even if the financial companies are empty today. Adding a financial company and reassigning enterprise units after production use requires journal reversals, WIP transfers, and opening balance migrations that create audit trail complexity disproportionate to the restructuring.

Sharing Too Much Through Logical Table Linking

The temptation to maximise data consistency by sharing as many tables as possible through logical table linking is understandable but counterproductive. Tables that carry company-specific configuration – pricing structures, production parameters, costing methods – must not be shared. Sharing them creates a single-point-of-failure configuration where a parameter change intended for one site affects all sites simultaneously. Map the mandatory-share tables (the ones LN requires to be shared for the structure to function) separately from the optional-share tables, and make an explicit governance decision for each optional table based on whether the organisational need is for consistency or independence.

Incomplete Transfer Pricing Rule Coverage

ITR transfer pricing rules must cover the full combinatorial space of entity relationships in the enterprise structure. In complex structures with many enterprise units, the number of entity-pair relationships grows rapidly. Implementations that configure transfer pricing rules only for the most common flows and leave edge cases uncovered produce zero-price internal invoices when an uncommon transaction type crosses an entity boundary – a problem that is frequently not discovered until period-end close reveals unexplained cost variances.

Missing Intercompany Relations by Currency

In multi-currency deployments using the standard currency system, the Intercompany Relations by Currency session (tfgld0122m000) must be configured for every transaction currency that crosses a company boundary. Implementations that configure only the Intercompany Relations session (tfgld0515m000) and omit the currency-level configuration produce missing intercompany posting errors on the first transaction in a currency not explicitly covered. These errors do not surface in single-currency testing environments, making them a classic category of go-live failure for global implementations.

Treating the Exchange Module as a Real-Time Mechanism

Exchange is a batch mechanism. Using it for data that requires near-real-time consistency across servers – inventory availability data used in sales order promising, production schedule data needed for cross-site capacity planning – creates operational errors when the current state of the source system diverges from the cached state in the target system between exchange runs. ION-based synchronisation or a query architecture that reads from the source system in real time is the correct approach for data with tight consistency requirements.

Connecting LN Multi-Site Architecture to the Broader Infor Ecosystem

A well-designed LN multi-site structure is the data foundation for the entire Infor manufacturing ecosystem. Sama’s detailed analysis of Infor ION’s role in enterprise integration covers how ION’s BOD-based architecture connects LN companies to CRM, WMS, CPQ, and analytics platforms. The enterprise unit and accounting entity identifiers published by LN through ION are the unique keys that downstream systems use to attribute transactional data to the correct legal entity and financial reporting context.

For manufacturers running Infor Factory Track for shop floor execution, the Factory Track-to-LN integration path relies on the same enterprise unit and company structure covered in this post. Factory Track transactions post to LN financial companies through the BDE web services layer, and those postings are routed to the correct intercompany accounts based on the enterprise unit assignments of the departments and warehouses involved.

For manufacturers evaluating migration to Infor CloudSuite, the multi-site architecture design decisions covered here remain directly applicable. CloudSuite Industrial and Infor LN share the enterprise unit and multi-company framework, and multi-site structure design is as critical in a cloud deployment as in an on-premises one – arguably more so, because cloud deployment constraints make post-go-live restructuring even more operationally complex.

Final Thoughts

Infor LN’s multi-site architecture is powerful enough to model virtually any global manufacturing enterprise structure accurately. The logistic company, financial company, enterprise unit, and site hierarchy is flexible in a way that few other ERP platforms match. But that flexibility comes with a direct proportionality between design quality and deployment quality. An enterprise structure designed carelessly, a data sharing strategy decided without a full table reference analysis, or an intercompany transaction setup that covers only the common flows will produce a system that runs but misleads – one where the numbers look plausible until period-end close reveals the cost variances and posting imbalances that have been accumulating since go-live.

The practitioners who produce multi-site LN deployments that hold up over time are those who treat the enterprise structure design as a distinct project phase with its own deliverable – a documented enterprise model with every entity mapping, every data sharing decision, every intercompany relationship, and every transfer pricing rule fully specified before a single company is created in the system.

Sama Consulting has supported Infor LN implementations across complex multi-site, multi-country manufacturing environments, including enterprise structure design, intercompany trade configuration, and ION-based data synchronisation architecture. If your organisation is planning a multi-site LN deployment or dealing with structural issues in an existing one, our Infor LN consulting practice covers the full technical depth of what is described here.