Workday Intercompany Accounting Configuration: Automated Elimination Entries and Cross-Company Settlement Workflows

Intercompany accounting in Workday is one of the most architecturally demanding areas of the Financial Management module. It sits at the intersection of the company hierarchy, the chart of accounts, the accounting rules engine, the intercompany framework configuration, and the consolidation reporting layer. When it is configured correctly, intercompany transactions balance automatically, elimination entries generate without manual intervention, and settlement workflows route to the right counterparty companies for approval. When it is configured incorrectly, the failures are subtle: balances do not eliminate cleanly at consolidation, intercompany payables and receivables drift out of sync between companies, and settlement workflows stall because the routing logic cannot resolve the counterparty.

This guide is for Workday Financial Management architects and accounting system administrators responsible for configuring or troubleshooting intercompany accounting in a multi-company Workday tenant. It covers the full configuration stack: company hierarchy setup, intercompany accounting rules, the intercompany framework object model, automated elimination configuration, cross-company settlement workflow architecture, matching and reconciliation mechanics, and the failure patterns that produce out-of-balance intercompany positions in production environments.

The Company Hierarchy and Its Role in Intercompany Configuration

Every intercompany transaction in Workday involves at least two Company business objects: the initiating company and the counterparty company. The relationship between these companies in the company hierarchy determines which intercompany rules apply, how elimination entries are generated, and which consolidation hierarchy the transactions roll up through.

Workday’s company hierarchy is built using the Company Hierarchy configuration object, which defines parent-child relationships between Company instances. The hierarchy is not flat: a global enterprise may have a parent holding company with subsidiary operating companies, which in turn have their own subsidiary entities. Intercompany rules and elimination configurations must account for all levels of the hierarchy because transactions can occur between companies at any level of the tree.

The consolidation hierarchy is a distinct object from the company hierarchy. A consolidation hierarchy defines which companies are included in a specific consolidation view and the elimination company used to book elimination entries for that consolidation. A single Workday tenant can have multiple consolidation hierarchies for different reporting purposes: a statutory consolidation hierarchy, a management reporting hierarchy, and a segment reporting hierarchy. The intercompany elimination configuration must be aligned to the correct consolidation hierarchy because the elimination company reference in the intercompany rule points to the company that holds the elimination journal entries, and that company is defined within the consolidation hierarchy configuration.

The elimination company is a special-purpose Company instance created specifically to hold intercompany elimination entries. It does not represent a legal entity and does not have workers assigned to it. Its sole function in the data model is to serve as the booking entity for elimination journal entries generated during consolidation. The elimination company must exist in the company hierarchy and must be included in the consolidation hierarchy at the level where elimination is required. A consolidation hierarchy that includes subsidiary companies but does not include the elimination company at the corresponding level does not generate elimination entries for transactions between those subsidiaries.

Intercompany Framework: Object Model and Configuration Sequence

Workday’s intercompany framework is built from four primary configuration objects that must be set up in a specific sequence because each references the previous. The sequence is: Intercompany Profile, Intercompany Rules, Intercompany Accounting Rule Set, and the assignment of the rule set to the relevant companies.

The intercompany profile defines the account pairs used to record intercompany transactions. It specifies the due-to account used to record intercompany payables and the due-from account used to record intercompany receivables. These accounts must exist in the chart of accounts and must be configured as intercompany account types. In Workday’s chart of accounts, the Account Type field on each account record determines how the account is treated in consolidation. Accounts designated as intercompany balance sheet accounts are candidates for elimination during consolidation. Accounts not designated as intercompany account types are not included in Workday’s automated elimination logic regardless of whether they carry intercompany balances in practice.

The intercompany profile also carries the Intercompany Receivable Offset account and the Intercompany Payable Offset account, which are used for the double-sided entry when an intercompany transaction is recorded. When company A purchases services from company B within the same consolidated group, company A records a debit to the relevant expense account and a credit to the intercompany payable account defined in the profile. Company B records a debit to the intercompany receivable account and a credit to the relevant revenue account. The offset accounts ensure the entry is balanced on both sides of the intercompany transaction.

Intercompany rules define the conditions under which intercompany accounting entries are generated. An intercompany rule specifies the trigger condition, the initiating company, the counterparty company, the intercompany profile to apply, and whether the rule generates automatic accounting entries or requires manual confirmation before the entries are created. The trigger condition uses Workday’s accounting rules condition framework, which evaluates journal line attributes: the account, the cost center, the company, the spend category, the revenue category, and any custom worktag dimensions configured on the tenant. A rule with no conditions applies to all journal lines that involve the specified initiating and counterparty company pair. A rule with conditions applies only to journal lines that match the condition criteria, which allows different intercompany profiles and accounting treatments to apply to different transaction types between the same company pair.

The counterparty company reference on an intercompany rule is a single-value field. A rule applies to transactions between exactly one initiating company and one counterparty company. For a tenant with ten operating companies that all transact with each other, the number of required intercompany rules scales as a combination of company pairs times the number of distinct transaction type conditions. Large multi-company tenants require a structured naming convention and a rule inventory document to manage the rule set at scale.

The intercompany accounting rule set is a container object that groups related intercompany rules together and is assigned to companies. The rule set assignment on a Company record determines which intercompany rules apply when that company initiates or participates in an intercompany transaction. A company can be assigned to only one intercompany accounting rule set, which means all intercompany rules that need to apply to a company must be included in a single rule set. The rule set assignment is made on the Company record itself through the Intercompany Accounting Rule Set field in the company’s financial configuration section and requires the Edit Company security permission. Changes to a company’s rule set assignment take effect immediately for new transactions but do not retroactively reprocess prior period transactions recorded under the previous rule set assignment.

Automated Elimination Entry Configuration

Automated elimination entries are the mechanism through which Workday removes intercompany balances from consolidated financial statements without manual journal entry. The automated elimination process runs as part of the consolidation close process and generates journal entries in the elimination company that offset the intercompany balances recorded in the individual subsidiary companies.

Workday’s automated elimination logic identifies intercompany balances by matching transactions that used intercompany-designated accounts across the companies included in a consolidation hierarchy. The matching is based on the counterparty company reference that Workday records on each intercompany journal line at the time the transaction is processed. When an intercompany rule generates accounting entries, Workday stamps the resulting journal lines with the counterparty company reference. This stamp is the data attribute that the elimination engine uses to pair the payable and receivable sides of an intercompany balance.

The counterparty company stamp is populated only when the intercompany rule fires. Transactions that involve intercompany accounts but were booked manually without triggering an intercompany rule do not carry a counterparty company stamp. Manual journal entries to intercompany accounts do not generate counterparty company references unless the journal entry is explicitly configured to include the intercompany reference field. Intercompany balances from manual journals without counterparty stamps are not eliminated automatically: they appear as uneliminated intercompany balances in consolidation reports and must be resolved through manual elimination journal entries or by retroactively adding the counterparty reference to the original journal line through a journal amendment.

When the consolidation close process runs, Workday evaluates the intercompany account balances across all companies in the hierarchy. For each matched intercompany pair where both the payable and the receivable carry consistent counterparty references, Workday generates an elimination journal entry in the elimination company that debits the intercompany payable account and credits the intercompany receivable account for the matched amount. The elimination entry is dated as of the consolidation period end date. If the payable balance in company A and the receivable balance in company B do not match, the elimination entry is generated for the matched portion and a residual uneliminated balance remains. The residual is reported in the consolidation’s intercompany matching exception report.

In multi-currency Workday tenants, intercompany transactions between companies with different functional currencies require currency translation before elimination entries can be generated. Workday translates intercompany balances to the consolidation currency using the exchange rate configured for the consolidation hierarchy. The translated amounts on the payable side and the receivable side may not match exactly due to exchange rate movements between the transaction date and the balance sheet date. This translation difference is recorded as a currency translation adjustment in the elimination company rather than as an uneliminated intercompany balance. The Currency Translation Adjustment account used for this purpose must be configured in the elimination company’s chart of accounts mapping and must be excluded from the intercompany matching logic so that it does not appear as a new intercompany balance requiring elimination.

Cross-Company Settlement Workflow Architecture

Intercompany settlement is the process through which intercompany balances are settled between companies through actual cash or netting transactions. In Workday, cross-company settlement workflows are built on the Business Process Framework and use the intercompany framework’s settlement configuration to route approval tasks to the correct counterparty company stakeholders.

The settlement workflow begins with the intercompany settlement proposal, which is a Workday transaction object that captures the proposed settlement amount, the settling companies, the settlement period, and the settlement method. The settlement method field determines whether the settlement is processed as an actual cash payment between the companies, a netting arrangement where offsetting balances are combined before settlement, or a simple accounting entry that reallocates the intercompany balance without a cash movement.

The Intercompany Settlement business process in Workday has a delivered definition that includes approval steps for both the initiating company’s approver and the counterparty company’s approver. The routing of each approval step uses the role-based security group resolution covered in the Workday Business Process Security Policies technical guide. The Intercompany Approver role must be assigned to the relevant company contact at each operating company for the routing to resolve correctly.

The failure mode when the Intercompany Approver role is not assigned at the counterparty company is that the approval step for the counterparty cannot be routed, and the settlement transaction stalls in the business process queue. Unlike some approval routing failures that produce an explicit routing error visible in the transaction, intercompany settlement routing failures sometimes present as a pending transaction with no assigned approver and no error message. Diagnosing this requires navigating to the business process instance record, identifying the current step, and examining the step’s routing resolution to find the missing role assignment.

For companies with multiple simultaneous intercompany balances in both directions, netting arrangements combine the offsetting payable and receivable balances before settlement to reduce the cash movement required. Workday’s netting configuration is defined on the Intercompany Settlement Profile, which specifies which account pairs are eligible for netting and the netting calculation method. The netting calculation produces a net settlement amount that is either a payable from company A to company B or a receivable from company B to company A, depending on which direction the net balance runs. Netting is only available when both sides of the intercompany balance are denominated in the same currency or when the settlement profile is configured to perform cross-currency netting with a defined exchange rate source.

When the settlement workflow completes all required approvals, Workday posts the settlement journal entries. For cash settlement, the entries debit the intercompany payable in the paying company and credit the cash account, and credit the intercompany receivable in the receiving company and debit the cash account. For netting settlement, the entries offset the payable and receivable accounts directly without a cash movement. The settlement entries are stamped with the settlement transaction reference, which provides the audit trail linking the settlement to the original intercompany transactions that established the balance.

Intercompany Matching and Reconciliation Mechanics

Intercompany matching is the continuous process of verifying that the balances recorded by each company in an intercompany transaction pair are consistent with each other before the period close. Workday provides delivered intercompany matching functionality through the Intercompany Matching worklet and the associated reports.

The matching process compares the intercompany balances by company pair and by account using the counterparty company stamp on journal lines as the matching key. Workday’s delivered “Intercompany Balance by Company Pair” report shows the balance recorded in each company for each intercompany relationship as of a specified date. When the payable balance in company A equals the receivable balance in company B after currency translation, the pair is matched. When they differ, the report shows the variance.

The most common sources of intercompany matching exceptions in a correctly configured Workday tenant are timing differences, currency differences, and manual journal entries without counterparty stamps. Timing differences occur when one company records an intercompany transaction in the current period and the counterparty company records the corresponding entry in the following period. For period-end matching, timing differences produce artificial exceptions that resolve when the subsequent period’s entries are posted. The investigation requires reviewing the journal line dates on both sides of the pair to confirm the entries exist and are simply in different periods. Currency differences are the translation adjustment variances described in the elimination section and are expected in multi-currency environments. Manual journal entries without counterparty stamps require direct investigation of the journal entries contributing to the intercompany account balance, using a journal line detail report filtered to the intercompany accounts for the specific company, period, and counterparty company, identifying any journal lines with a blank counterparty company field.

For organizations that require formal sign-off on intercompany matching before the period close is finalized, Workday supports a period-end reconciliation business process that routes the intercompany matching exception report to the designated reconcilers at each company for review and approval. The reconciliation workflow is configured as a custom business process in the Financial Close domain and can be sequenced within the overall period close business process to prevent consolidation from proceeding until intercompany matching is approved. Adding the intercompany reconciliation as a condition-dependent step that must complete before the consolidation close step ensures that consolidation does not run with unresolved intercompany exceptions. The condition rule on the consolidation close step evaluates whether any open intercompany matching exceptions exist for the current period.

Worktag Propagation in Intercompany Transactions

Worktags are the dimensional accounting attributes in Workday Financial Management: cost center, project, region, fund, grant, and custom dimensions. In intercompany transactions, worktag propagation determines whether the worktags on the initiating company’s journal line are carried to the counterparty company’s automatically generated journal line.

Worktag propagation behavior is configured on the Intercompany Profile through the Propagate Worktags setting. When propagation is enabled, the worktag values from the initiating company’s journal line are copied to the intercompany accounting lines generated for the counterparty company. When propagation is disabled, the counterparty company’s intercompany accounting lines carry no worktag values beyond the company and account references.

The decision to enable worktag propagation is not straightforward. Propagating the initiating company’s cost center to the counterparty’s intercompany receivable line adds cost center dimensionality to the counterparty’s balance sheet, which can be useful for segment reporting but can also produce dimension combinations that are not valid in the counterparty company’s chart of accounts configuration. Workday validates worktag combinations against the account-worktag validation rules configured on the counterparty’s chart of accounts. A propagated worktag that violates the counterparty’s validation rules prevents the intercompany accounting entry from being generated, which blocks the original transaction from posting. For this reason, worktag propagation in intercompany transactions requires explicit testing of the worktag combinations that will be produced across each company pair and each transaction type before enabling propagation in production.

When the initiating company and the counterparty company use different cost center hierarchies or different dimension value sets, direct propagation produces invalid worktag combinations in the counterparty. For these environments, Workday supports intercompany worktag mapping rules that translate the initiating company’s dimension values to the counterparty’s equivalent values before propagation. The mapping rules are configured on the Intercompany Profile as a translation table: source company dimension value to target company dimension value. The mapping must be maintained as dimension value sets change in either company. A mapping table with stale entries produces propagation failures when the source company retires a dimension value that the mapping table still references.

Security Domain Configuration for Intercompany Accounting

Intercompany accounting configuration spans multiple security domains in Workday Financial Management. The domains most directly relevant to intercompany setup and operation are organized under the Financial Management functional area.

Set Up: Financial Management controls access to the core intercompany configuration objects: Intercompany Profile, Intercompany Rules, Intercompany Accounting Rule Set, and their assignment to companies. This domain should be restricted to Workday Financial Management system administrators and the Finance IT team responsible for chart of accounts and accounting rules configuration. Broad access to this domain allows workers to modify intercompany rules, which directly affects how transactions are recorded across all companies in the tenant.

Process: Intercompany Settlement controls who can initiate, approve, and post intercompany settlement transactions. The initiation access should be assigned to treasury or intercompany accounting teams. The approval access must be assigned to the Intercompany Approver role holders at each company, using role-based security groups scoped to the relevant company to ensure approvers can only act on settlements for their own company.

Reports: Financial Accounting covers access to intercompany matching reports, intercompany balance reports, and consolidation exception reports. Finance controllers, corporate accounting teams, and external audit support roles typically need this access. The scope of the security role assignment limits the companies whose data is visible in these reports.

Set Up: Consolidation controls the consolidation hierarchy configuration, the elimination company designation, and the consolidation close parameters. This domain should be the most tightly restricted of the intercompany-related domains because changes to consolidation hierarchy configuration affect every automated elimination run across all historical periods that are recalculated.

According to Workday’s Financial Management configuration documentation, the intercompany and consolidation security domains are governed by the standard Workday domain security policy framework, and changes to policies in these domains require activation through the pending security policy change process before taking effect.

Integration with the Accounting Rules Engine

Workday’s Accounting Rules Engine is the framework that governs how business transactions are translated into journal entries. Intercompany accounting rules are a specific category of accounting rules within this engine, and they interact with the broader accounting rules configuration in ways that affect the sequencing and completeness of intercompany entry generation.

The accounting rules evaluation sequence in Workday processes rules in a defined priority order. Standard accounting rules that govern expense and revenue recognition fire before intercompany accounting rules. The standard rules produce the primary journal lines. The intercompany rules then evaluate those primary lines and generate the intercompany accounting entries based on the company references they find. This sequencing means that if a standard accounting rule produces a journal line with an incorrect company reference due to a cost center-to-company mapping error, the intercompany rule evaluates the incorrect company reference and generates the wrong intercompany entries.

Cost center to company mapping is maintained in Workday’s organization hierarchy configuration. Each cost center is assigned to a Company through the Company field on the Cost Center record. When a transaction is coded to a cost center, Workday derives the company from the cost center’s company assignment. A cost center with a stale company assignment after an organizational restructure produces transactions recorded under the wrong company, which generates intercompany entries between the wrong company pair, which produces unbalanced intercompany positions at consolidation. The diagnostic approach for intercompany entries posting to unexpected company pairs is to review the cost center company assignments for the cost centers involved in the misrouted transactions and compare them against the current organizational structure.

Common Production Failure Patterns

Six failure patterns account for the majority of intercompany accounting production issues in multi-company Workday deployments.

Elimination entries not generating for specific company pairs almost always trace to one of three conditions: the companies are not both included in the consolidation hierarchy at the level where elimination is configured, the intercompany accounts used in those transactions are not designated as intercompany account types in the chart of accounts, or the journal lines do not carry counterparty company stamps. All three conditions must be true for automated elimination to fire. The diagnostic sequence checks them in that order.

Settlement workflow stalling with no assigned approver is caused by a missing Intercompany Approver role assignment at the counterparty company. Navigate to the business process instance for the stalled settlement, identify the current unrouted step, and verify the Intercompany Approver role assignment for the counterparty company in the relevant security group.

Intercompany matching exceptions from manual journals occur when finance teams post manual journals to intercompany accounts without completing the counterparty company reference field. The prevention is a Journal Validation Rule that enforces field completion on any journal line coded to an intercompany account type. Workday supports journal validation rules through the Journal Validation Rule configuration object, which can enforce field completion requirements on journal entry templates and manual journal posting.

Worktag propagation blocking transaction posting occurs when a propagated dimension value violates the counterparty company’s account-worktag validation rules. The error message identifies the validation rule that was violated but may not clearly indicate that the failure is on the counterparty company’s generated line rather than on the original transaction’s primary line. The fix requires either adding the propagated worktag value to the counterparty company’s allowed dimension combinations or using a worktag mapping rule to translate the initiating company’s dimension value to a value that is valid in the counterparty’s configuration.

The currency translation adjustment appearing as an uneliminated intercompany balance occurs when the CTA account used in the elimination company is not excluded from the intercompany matching logic. Translation adjustments then appear as new intercompany balances requiring elimination, creating a self-referential elimination loop. The fix requires reviewing the intercompany account designation of the CTA account in the elimination company and ensuring it is not classified as an intercompany account type.

An intercompany rule not firing for specific transaction types is diagnosed by comparing the condition criteria on the rule against the actual journal line attributes of the transactions that are not triggering it. The most common cause is a condition referencing a spend category or revenue category mapped differently in the source data than in the rule’s condition. Workday’s accounting rule testing capability allows administrators to submit a test transaction through the accounting rules engine and observe which rules fire and which do not, isolating the condition mismatch without requiring live transaction posting.

Designing for Operational Accuracy at Scale

Intercompany accounting configurations that hold their accuracy over a multi-year deployment require explicit governance, systematic testing, and alignment to every organizational change that affects the data the rules evaluate.

Define a change management policy for intercompany rule modifications that requires testing in sandbox against representative transaction samples before production deployment. An intercompany rule change that produces incorrect entries does not generate a system error: the entries post successfully but they are wrong, and the error surfaces only at the next period close when the intercompany matching exception report reveals out-of-balance positions.

Review cost center company assignments as part of every organizational restructure. Intercompany entries are only as accurate as the company references derived from cost center assignments. A cost center moved to a new company in the organizational hierarchy without a corresponding update to its Workday Company assignment generates intercompany entries for the old company pair for every transaction coded to that cost center until the assignment is corrected.

Maintain a documented inventory of all intercompany rules, their company pair scope, their transaction type conditions, and the intercompany profile they apply. At scale, the rule set becomes opaque without documentation, and new rules added to address edge cases create overlaps and conflicts that are difficult to diagnose without a rule inventory.

For Financial Management architects designing intercompany accounting for a multi-company Workday deployment, or for accounting teams managing a production environment where intercompany balances do not eliminate cleanly at period close, the team at Sama brings Workday Financial Management configuration depth across the full intercompany stack.