Multi-entity reporting in Workiva: getting the setup right

An entity’s statutory accounts and its contribution to the group report can use different accounting bases, currencies, and adjustments. List the outputs due for each entity, the ledger they start from, the reporting period, and the preparer and reviewer. Note local requirements, including language and filing deadlines. Record any entity that is excluded and why.

Then agree where the accounting work happens. Which system calculates currency translation and intercompany eliminations? Where are local and group adjustments approved? Which balances will arrive in Workiva ready to report? Workiva’s multi-entity solution connects with ERP and consolidation tools. A Wdata table or query needs a defined source for the approved accounting results it uses.

Keep those decisions beside the report list. They determine which balances each report needs and which checks its reviewer should see.

Suppose two entities both use account 4000. In one ledger it is product revenue; in the other it is intercompany revenue. A lookup on the account code alone can put both balances on the same line.

Use a mapping key that distinguishes the source accounts. That may mean entity plus account code, or source ledger plus account code where entities share a chart. Keep the original code and description beside the reporting line, along with the sign convention and the period the mapping applies to. An entity may need separate mappings for its local accounts and the group report.

Workiva’s financial-statement setup guide describes trial-balance, entity, and chart-of-accounts mapping tables. Finance should be able to review the mappings and name who approves changes. If a new account has no mapping, show its balance on an exception list until someone decides where it belongs.

Check for duplicate matches too. If a trial-balance row joins to two mapping rows, its amount can appear twice in the result. For each report, every source balance should be accounted for once, with any intentional split documented and checked.

For a Wdata setup, trace one entity through the whole route:

1. Load its trial balance and compare the imported rows and totals with the ledger extract. Record the entity and period. Confirm whether a rerun replaces the previous load or adds another batch.
2. Run the query with explicit entity and period selections. Apply the right mappings and check for missing accounts, duplicate matches, and rows from another period.
3. Bring the query results into a connected spreadsheet. Use a separate reporting sheet with stable rows for calculations, approved adjustments, and tie-outs. Pull balances into those rows by entity and reporting line. Linking from fixed cell positions in a raw query result can pick up the wrong balance if the rows move after a refresh.
4. Link the report tables and recurring figures to that reporting sheet. After a change, refresh the connection, check the reporting sheet, and publish the changed source links. Then check the figures in the destination report.

A revised load can be correct while the spreadsheet still holds the previous query result. The spreadsheet can also be current while a document is waiting for link publication. Write down both steps so the next preparer knows how a ledger correction reaches the report. The report-not-updating guide covers those checks.

Compare the imported trial balance with control totals from the approved ledger extract. Then account for the full imported balance in the mapped reporting lines and the exception list. Comparing two formulas that use the same incomplete query will miss anything the query left out.

Tie the statements to the approved balances for that report’s accounting basis. Keep local adjustments, currency translation, eliminations, and group adjustments identifiable where they apply. A local statutory result may differ legitimately from the entity’s contribution to the group accounts; the reconciliation should explain the difference.

Check the report itself as well. Its tables should agree with the spreadsheet, repeated figures should agree across the notes, and prior-period figures should match the approved comparative amounts. If a comparative was restated or reclassified, retain the reconciliation and approval for that change.

A common table layout and shared wording can save repeated editing. Local accounting policies, statutory notes, language, and currency still need an entity-specific decision.

For example, two reports may use the same revenue table but need different accounting-policy text. Share the parts that match and keep the local wording separately maintained. Name who reviews each local requirement, and record which reports use each shared source so a change can be checked in all of them.

Track work in terms the team can act on: source received, accounts awaiting mapping, ready for review, returned for correction, approved, filed. Put an owner and a due date beside each report. Keep filing confirmation with the final version so the group team can see what was submitted.

Choose a few entities that expose the differences in your group: a straightforward one, one with a different chart or currency, and one with a local reporting requirement. Use a closed period whose approved reports are available for comparison.

Run the loads, mappings, reports, and review steps for that period. Investigate every difference. Then have the person who will own the process run it from written instructions, including a corrected load and an unmapped account. Extend the setup once they can reproduce the approved results and handle those exceptions.

For the next cycle, record what changes: period selections, source files, mappings, comparatives, report dates, and reviewers. The Workiva reporting project worksheet helps collect the starting files; the first roll-forward guide covers checks when copying reports into a new period.