During Quest Forum Digital Event: Cloud Week, attendees learned about how Crowley Maritime balanced intercompany transactions functionality, key configurations, and its Oracle ERP Cloud implementation.

The presentation dove into a basic understanding of intercompany transactions functionality in ERP Cloud, key configurations that affect intercompany transactions and intercompany balancing in subledgers, and how a company with significant intercompany accounting requirements approached its implementation and uses Oracle ERP Cloud.

About Crowley Maritime

Crowley Maritime provides marine solutions, energy, and logistics services from its headquarters in Jacksonville, Fla. With roughly 5,300 employees, the company operates more than 200 operating vessels in North and Central America with annual revenues of more than $2 billion.

Crowley went live on Oracle ERP Cloud in July 2019 and HCM Cloud in January 2020. Previously, the company used Lawson and Peoplesoft to manage six primary ledgers, 60 legal entities, and roughly 120 balancing segment values across more than 100 general ledger users in seven countries. Crowley managed a high volume of intercompany business transactions and needed a more effective accounting solution.

Maintaining Balance in the Cloud

Intercompany transaction functionality allows users to enter transactions that use different balancing segments, legal entities, and ledgers. While other subledgers and GL journals create intercompany balancing entries, only intercompany transaction functionality creates entries between legal entities/balancing segments that are associated with different ledgers. The different ledgers are the key differentiator here.

General Process Flow

Deploying intercompany functionality starts with entering an intercompany transaction or a journal entry executed by a provider organization (i.e., the supplier, or company sending out an accounts receivable invoice).

The system evaluates whether the transaction requires an invoice, and if it does, whether it requires approval. If the transaction does not require approval, the system generates an accounts receivable invoice through an auto-invoice process, as well as an associated supplier invoice for the receiver of the transaction. Should an invoice require approval, the receiver can add distributions and approve the intercompany transactions.

If the transaction is a journal type, and no approval required, the transaction can transfer to a general ledger, and journal entries in each ledger are created, as a journal import and a posting process. If approval is required, the receiver can add a distribution account.

This process flow allows for two paths:

1. One that creates accounts receivable and accounts payable invoices
2. One that results in multiple GL journal entries

If the transaction needs no approval, users can also opt to enter both the provider and receiver distributions and send them straight through to AR and AP, or a general ledger.

An intercompany transaction contains three basic components:

1. The batch, which determines the provider organization (‘due to”) and transaction type
2. Transactions, which determine the receiver organization (“due from”) amount
3. Distributions, or the account distributions for both provider and receiver

Configuration Key Points

When configuring intercompany functionality, consider intercompany balancing rules. These rules generate account combinations that result from journals that are unbalanced by a legal entity or primary balancing segment value. The four balancing rules will be evaluated in the following order:

1. Primary balancing segment values
2. Legal entity
3. Ledger
4. Chart of accounts

Primary balancing segment values provide a map from ledgers, legal entities, and primary segment values. Use this configuration when you need to map an intercompany payable or receivables account down to a specific primary segment value. This method is rarely needed because it is cumbersome and labor-intensive.

The less complex and less detailed legal entity rules map from a ledger to a ledger, and from a legal entity to a legal entity, thereby removing the balancing segment value from the rule. Ledger rules map from ledger to ledger. The least detailed chart of accounts rules map to and from the chart of accounts and should always be configured even if your business is using other rules types, thus ensuring intercompany transactions won’t fail due to account generation.

When choosing the appropriate intercompany balancing rule, use the most general type of rule that fulfills your requirements. It’s going to be far less maintenance in the long term to use a more general rule than a more specific rule unless it’s required. Consider if the non-BSV segments vary by ledger, LE, or primary segment. If non-BSV segments don’t vary from the general rule, use the Chart of Accounts rule.

Transaction types control two key aspects of intercompany transaction processing:

1. Intercompany AR/AP invoice generation vs GL journals
2. Approvals via BPM versus no approvals required

Intercompany system options control how transactions behave—automatic versus manual batch numbering, minimum transaction/currency amounts, the conversion rate type used unless it’s overwritten by the transaction type, as well as the intercompany calendar and the default transaction type.

Intercompany organizations associate transactions with a legal entity, and clients use these to enter provider/receiver organization on intercompany transactions. Many organizations may be associated with a single legal entity. These organizations are also used to secure data access. A new organization means new data access for users. When defining, clients should consult AR and AP teams to ensure correct business units are being assigned to the right intercompany organization.

Intercompany customer/supplier associations define which customer account or supplier site will be used for intercompany AR/AP transactions. Customer and supplier sites must be marked as “primary.” Interface processes to AR/AP will fail if sites are not properly configured. Intercompany receivables assignments determine the accounts receivable transaction type and memo line that will be used to create the AR invoice. Clients should coordinate with the AR implementation team to ensure transaction types meet requirements for accounting and reporting.

Intercompany balancing and clearing options control summarization of intercompany balancing journal lines and how to manage many-to-many journal balancing. Using a clearing account is essentially required if journals with many-to-many are created. Intercompany approvals use Oracle Business Process Management to route and manage approvals and require configuration of OBPM. The existing default flow in OBPM will need to be updated to meet organizational requirements.

Transaction Account Definitions and Transaction Account Builder are rules that provide the ability to automatically generate account distributions for both provider and receiver. It’s the same functionality as transaction account builder in other subledgers. These tools are not the same as subledger accounting, but similar in that they both use rules to determine accounts.

To maintain security, clients should consider seeding a role called Intercompany Accountant. This person will help the client avoid issues by double-checking whether users have proper intercompany organization access.

Under Lawson, Crowley essentially allowed cross-ledger journals, so taking on a new intercompany system necessitated a new approach. Clients should deploy extensive testing as they navigate the learning curve and adapt these new processes.

To learn more, check out the Quest Forum Digital Event presentation below.