Duplicate mappers delayed dual reporting; OneStream rules mapped ERP transactions to both frameworks with review

Overview

A multinational company needed parallel financial reporting under International Financial Reporting Standards (IFRS) and U.S. Generally Accepted Accounting Principles (US GAAP), but maintained separate spreadsheets, mappings, and journal workflows for each framework. Differences in leases, development costs, impairment, inventory, revenue, and consolidation created recurring rework and reconciliations at quarter end. Intelligex implemented a rules engine that mapped transactions and adjustments to both frameworks, surfaced conflicts for finance review, and generated dual consolidated statements in OneStream. Reporting teams worked from one controlled source, variance analysis focused on policy rather than mechanics, and reconciliation between frameworks required less rework—without changing ERPs or core consolidation processes.

Client Profile

• Industry: Diversified global manufacturer and distributor
• Company size (range): Multi?entity, multi?currency operations across regions
• Stage: Established ERPs and consolidation; dual reporting handled with separate spreadsheets, mappers, and late top?side journals
• Department owner: Finance & Accounting (Corporate Controllership)
• Other stakeholders: Regional Accounting, Technical Accounting, FP&A, Tax, Treasury, IT/Integrations, Internal Audit, External Auditors

The Challenge

Dual reporting depended on duplicate processes. Local ledgers posted under a single policy set, then separate spreadsheets applied framework?specific adjustments. IFRS and US GAAP differences—lease classification and measurement, development cost capitalization vs. expense, impairment methodologies, inventory costing constraints, revenue recognition nuances, and consolidation scope—were managed in scattered workbooks. Mappings diverged by region, documentation varied by account owner, and late journals were used to force alignment with disclosure requirements.

Version control and evidence were weak. Each framework had its own mapper with inconsistent rule names and chart references. Effective dates were tracked in tabs, not in a governed registry. Supporting documentation for adjustments lived in email threads and shared folders, so reviewers reconstructed rationale when the same difference recurred. OneStream held consolidated results, but the path from transactional facts to framework outputs was opaque. External reviewers asked for clear ties from rule to journal to disclosure, and the team rebuilt support each cycle.

Why It Was Happening

Root causes were fragmented logic and the absence of a canonical data model for dual reporting. ERPs contained transactions and local policy adjustments, while framework differences were computed separately with manual filters and index?match formulas. There was no single rules engine that could evaluate an event, apply both IFRS and US GAAP treatments, and produce side?by?side outcomes with effective dating, rationale, and ownership. Conflicts were discovered late because mapping drift and overlapping exceptions were not surfaced as part of the close.

Ownership was diffuse. Corporate Controllership set policy, Technical Accounting interpreted guidance, regions posted local entries, and Consolidation teams reconciled results. Without a controlled layer to encode both frameworks and route conflicts with evidence, dual reporting depended on institutional knowledge and end?of?period remediation.

The Solution

Intelligex delivered a framework?aware rules engine and workflow that normalized source data, evaluated IFRS and US GAAP treatments in parallel, and posted approved adjustments into OneStream. The engine applied policy rules with effective dating, generated both frameworks’ trial balances and disclosures, and flagged conflicts for finance review with side?by?side calculations and citations. Practices aligned with guidance from the IFRS Foundation and the Financial Accounting Standards Board, and consolidated reporting leveraged OneStream.

• Integrations: ERP actuals and subledger summaries; master data for entities, charts, and currencies; OneStream for consolidation and reporting; optional data warehouse for historical comparisons.
• Canonical dual?reporting schema: Standard fields for account, entity, cost center, currency, transaction type, policy attributes (lease, R&D, impairment, inventory, revenue, consolidation), and framework flags.
• Rules engine: Finance?owned treatments for both frameworks with effective dates and rationale (for example, IFRS 16 vs. ASC 842 leases; IAS 38 vs. U.S. GAAP development costs; IAS 36 vs. ASC 350 impairment; IAS 2 inventory vs. ASC 330 approaches; IFRS 15 vs. ASC 606 nuances; IFRS 10 vs. ASC 810 consolidation).
• Conflict detection: Automated surfacing of mapping overlaps, stale effective dates, and rule contradictions; side?by?side comparisons and proposed resolutions.
• Adjustments and postings: Generation of framework?specific journals with linkbacks to rules and source transactions; safeguards to prevent double counting; automated load to OneStream.
• Disclosure support: Tagging of framework differences to disclosure lines and notes; evidence packs with rule text, rationale, and calculations.
• Approvals and governance: Maker?checker workflow for rule changes and high?impact journals; reason codes and attachments; immutable logs.
• Dashboards: Framework variance by account and entity, open conflicts, rule changes, and consolidation status; drill?downs to underlying entries and rules.

Implementation

• Discovery: Cataloged IFRS and US GAAP differences relevant to the client’s profile; inventoried ERPs, chart variations, and OneStream structures; reviewed historical adjustments and audit comments; identified recurring conflict patterns.
• Design: Defined the dual?reporting schema and identity crosswalks; authored framework rules with effective dating and ownership; specified conflict checks and reason codes; mapped journal posting patterns and disclosure linkages; planned dashboards and evidence exports.
• Build: Implemented data pipelines from ERPs; created the rules engine and calculation services; developed conflict detection and maker?checker workflows; configured OneStream loads and disclosure mapping; assembled dashboards and audit logging.
• Testing/QA: Ran in shadow mode: produced parallel IFRS and US GAAP balances and proposed entries while legacy spreadsheet methods continued; reconciled results to prior periods; tuned mappings and rules; exercised conflict routing with Controllership and Technical Accounting.
• Rollout: Enabled dual reporting for selected entities and topic areas first (for example, leases and development costs); retained spreadsheet outputs as a controlled fallback; expanded coverage as stability grew; tightened approval gates after training.
• Training/hand?off: Delivered sessions for Regional Accounting, Consolidation, and Technical Accounting on reading side?by?side calculations, approving conflicts, and tracing disclosures; updated SOPs for rule maintenance and evidence; transferred ownership of rules, mappings, and dashboards to Controllership under change control.
• Human?in?the?loop review: Established a recurring forum to review rule updates, conflict themes, and disclosure impacts; decisions recorded with rationale and effective dates.

Results

Dual reporting moved from duplicate, spreadsheet?based processes to a governed, rules?driven model. Framework treatments were applied in parallel from a single source, conflicts were flagged with context, and approved adjustments flowed into OneStream with traceable lineage. Close reviews focused on material policy differences rather than on reconciling divergent mappers.

Reconciliations and disclosures stabilized. Teams produced IFRS and US GAAP statements and notes from the same pipeline, with evidence packs that tied rules, journals, and source transactions. Audit and regulator questions were answered with consistent documentation. ERPs and OneStream remained; the change was a framework?aware rules layer and governance that aligned policy and execution.

What Changed for the Team

• Before: Separate spreadsheets and mappers by framework. After: A single rules engine produced IFRS and US GAAP outcomes in parallel.
• Before: Conflicts surfaced late in consolidation. After: Automated checks flagged overlaps and stale rules with side?by?side views.
• Before: Top?side journals varied by region. After: Framework?specific entries followed governed patterns with linkbacks to rules and sources.
• Before: Disclosure tie?outs were rebuilt each cycle. After: Differences were tagged to notes with evidence packs from the same pipeline.
• Before: Rule changes lived in email. After: Maker?checker approvals captured rationale and effective dates under change control.
• Before: Reviews focused on mechanics. After: Reviews focused on policy choices and business impacts.

Key Takeaways

• Model frameworks side?by?side; one rules engine should evaluate IFRS and US GAAP from the same facts.
• Version policy; effective?dated rules with ownership and rationale prevent drift and repeated debates.
• Surface conflicts early; automated checks and reason codes reduce late rework.
• Tie journals and disclosures to rules; evidence and lineage make audits and reviews straightforward.
• Integrate, don’t replace; keep ERPs and OneStream, and add a governed dual?reporting layer.

FAQ

What tools did this integrate with? Source actuals and subledger summaries flowed from the company’s ERPs, the rules engine produced framework?specific adjustments, and consolidated statements and notes were generated in OneStream. Policy references aligned to standards from the IFRS Foundation and the FASB.

How did you handle quality control and governance? Framework rules lived in a finance?owned registry with effective dating, owners, and rationale. Conflict detection flagged overlapping mappings, expired rules, and contradictions. High?impact entries and rule changes required maker?checker approvals with attachments. Every calculation, posting, and approval was immutably logged with linkbacks to source transactions and disclosure tags.

How did you roll this out without disruption? The engine ran in shadow mode first, producing IFRS and US GAAP balances side?by?side while existing spreadsheets remained in use. Differences were reconciled and rules tuned. Rollout began with selected entities and topics, expanded in waves, and stricter approval gates were enabled after training and stable cycles.

Which accounting differences were addressed? The library covered lease accounting, development costs, impairment testing, inventory costing and valuation, revenue recognition nuances, and consolidation scope. Each topic had framework?specific treatments with effective dates and references, so outcomes could be compared consistently across periods.

How were disclosures supported? Adjustments and classification differences were tagged to disclosure lines and notes in OneStream. Evidence packs included the applied rule, effective date, owner, and the calculation trail from source transactions to the reported amount, so note preparation used the same lineage as the balances.

What happened when standards or interpretations changed? Policy updates were proposed in the rules registry, reviewed by Technical Accounting, and approved through maker?checker with effective dating. The system preserved prior rule versions for historical periods and applied new treatments prospectively or retrospectively according to policy, with impacts visible in dashboards.