What is Workiva Wdata? A plain guide for finance and reporting teams

Most Workiva users start in spreadsheets, documents, and presentations. Wdata sits underneath them. Data is loaded into tables, shaped and combined with queries, and the query results are connected to Workiva spreadsheets, where they feed calculations and linked reports. Chains automate the movement: pulling data from a source system, loading it, and refreshing what depends on it. Workiva groups these, along with Data Prep, as its data management capabilities.

Each row is a separate step. A table can hold new data while a spreadsheet still shows the old query result, and a spreadsheet can be current while a linked document has not updated. When a number looks wrong, check each stage on its own; the report-not-updating guide walks through that.

Suppose a finance team receives one expense file each month and uses it in a management report. The fictional September file below has three rows and a source total of 80,000. It is a small example of the data path, not a reason to introduce Wdata for a three-row file.

Keep the extract and the mapping separate

Load the extract into a fact table with period, account, and numeric amount columns. Keep account codes as text if leading zeros matter. Record which source file supplied the load and preserve that file for reconciliation.

Put the reporting mapping in a separate dimension table: accounts 5100 and 5200 map to Operating expenses; account 5300 maps to Technology expenses. For this example, each account has one mapping. If the real reporting model maps by entity, department, or effective date as well, those fields belong in the mapping key too.

Query the selected period and check the mapping

Filter the extract to September 2026, relate it to the mapping, and summarize numeric amounts by reporting line. Check unmapped accounts separately; do not let an unmatched row disappear from the reported total. The expected result is:

The source has three rows, the mapped detail still has three rows, the result has two reporting lines, and both totals are 80,000. Check detail row counts before aggregation: a duplicate mapping can multiply an amount even when the final result has only two lines.

Connect the result to the spreadsheet

For a repeatable refresh, use the spreadsheet’s Connections panel to connect the query to a sheet and confirm its period parameter. Export to spreadsheet creates a snapshot; it is not the same as a refreshable connection. Workiva documents that distinction in its query-results guidance.

Keep the connected result separate from the reporting calculations. Confirm that the spreadsheet total is 80,000, then publish the approved source links and check the document’s reporting lines. A successful load alone does not establish that the report is current.

Test failures before scheduling the Chain

These are checks to design into the workflow, not automatic protections provided by every Wdata setup:

Once the manual path passes those checks, a Chain can retrieve the file, load it, run the checks, and refresh the connected sheet in order. Decide which failures stop the run, who receives the exception, and how that person safely reruns it. See Wdata and Chains consulting for help designing or repairing that path.

Wdata is worth the design effort when one or more of these is true:

• The same data feeds many reports. One trial balance load serving statements, management reports, and a board package.
• Inputs arrive every cycle from systems. An ERP, consolidation tool, or data warehouse that can be connected rather than exported by hand.
• Volumes are large. Transaction-level or multi-entity data that is unwieldy in a spreadsheet.
• You need history and governance. A record of what was loaded, when, and by whom, and the ability to reload a period.
• Mappings change. A mapping table in Wdata can be maintained separately from the reports that use it.

A single report with one small monthly upload, stable mappings, and one preparer often runs perfectly well from a spreadsheet with a controlled import. Adding Wdata there adds pieces to maintain without much benefit. Start simple and add Wdata when one of the conditions above appears.

Name things for the person who inherits them. Table, query, and chain names should say what they hold and which period or source they cover.

Keep mappings as data, not logic. A mapping table that finance can review and update is easier to maintain than mapping rules buried in query code.

Load, then check. Build a control total or row count check into every load, and make the result visible before anything downstream refreshes.

Separate raw from shaped data. Keep what came from the source unchanged, and do the shaping in queries. That makes it possible to answer “was it the source or our logic?”

Decide who fixes a failed run. Automated chains fail sometimes: an expired credential, a changed source file, a late extract. Name the owner and write down the first three checks before go-live.

Test with real permissions. Users may need specific roles to see or refresh data. Test the whole path with the accounts the team will actually use.

Wdata often underpins work that does not fit a standard report: structured data collection from many contributors, cross-team datasets, and reporting that combines finance and operational data. Those projects need the most careful design because they have the most moving parts. If you are weighing one, see custom Workiva solutions.