How To Build And Maintain A Sustainable Workday Foundational Data Model

For many organizations, shifting methodologies for processing financial transactions is easier said than done. Adopting and tailoring the Workday Financial Management Foundational Data Model (FDM) to record financial transactions can be overwhelming when migrating over from a more traditional “chart of accounts” (COA). We explain key concepts and share best practices to enable financial transformation within your enterprise by effectively leveraging Workday’s FDM.

What is the Foundational Data Model?

The Foundational Data Model (FDM) is a data framework that supports financial transaction processing, enriched reporting and security within Workday. It is similar in nature to a chart of accounts (COA) or segment structure in legacy ERP / financial systems. The FDM provides for the usage of Workday worktags to identify attributes of a specific transaction. Examples of worktags include general ledger accounts, cost centers, spend categories, revenue categories, locations, etc. Worktags assign attributes to financial and non-financial transactions for enhanced reporting purposes. This functionality is unique from other legacy ERP systems, as it allows for targeted detail with transactions and in reporting data.

Protiviti Foundation Data Model Worktag Chart

Guiding principles for FDM design

Organizations often grapple with how to design the FDM effectively so that it incorporates Workday concepts of a lean natural ledger account structure that leverages the power of worktags yet strikes a balance between the degree of transaction processing needed. Ultimately, the Workday FDM should provide a sustainable data framework that has the flexibility to support evolving business needs and future growth, is scalable and can be maintained efficiently. While there is no one-size-fits-all answer, we recommend that the following considerations drive the design of the FDM and utilization of worktags.

A well-designed FDM should:

• Allow room for growth and adaptability to changes in business views of business lines, products and markets
• Reduce or eliminate cumbersome manual data manipulation to support external financial and management reporting
• Optimize delivered Workday reporting dashboards and analysis capabilities
• Enable efficient time to close
• Right-size the level of detail recorded on each financial transaction
• Enable appropriate internal controls over reporting mechanisms

Foundation Data Model Drivers (Source: Workday)

FDM development/maintenance guiding principles

The FDM is comprised of all worktags that are owned and maintained by the FDM or Finance team. The FDM can be developed using Excel workbooks, or a combination of Excel supported by back-end databases using tools like Microsoft Access. Database tools could be used to automatically populate the FDM with data from the master files with XLOOKUP/VLOOKUP formulas. If the FDM is built directly into an Excel workbook, worktags can be compiled in tabs and built out accordingly with their configuration (i.e., ledger account ID, description, summary levels, etc.).

• Worktag structure – As previously mentioned, worktags are identifiers that classify transactions. Examples include spend categories where spend (expense) is recorded, revenue categories where revenue is recorded, or cost centers (i.e., departments) where cost associations like employee time are booked. Generally, worktags are organized in the FDM separately with their Workday designated account characteristics and a direct tie to their legacy system counterpart.
• Worktags are used as individual components in comprehensive legacy-to-Workday translators, also called crosswalks or maps, when necessary. The maps, which are maintained in the FDM Workbooks or database and in the Workday tenant itself, are used by integrations and various data conversion activities like general ledger conversions, to route legacy data to its Workday equivalent using account translations that are defined in the maps.
• One marked difference between other accounting systems charts of accounts and Workday’s FDM is that other systems might utilize many ledger accounts to bifurcate different sub-categories of activity. In Workday, account bifurcations are much more commonly delineated using worktags (i.e., spend/revenue categories).
• Reference IDs are unique identifiers for a worktag to be used in integrations, translators, reporting, etc. There can only be one worktag in Workday using a unique reference ID. It is best practice to sort the FDM (in Excel) by reference IDs created for Workday in sequential order to avoid the re-use of a unique ID.
• Hierarchical structures are used by worktags to enable streamlined reporting and organizational analysis. Hierarchies are commonly used on worktags and can be set up to allow for more targeted security configuration and reporting capabilities (i.e., cost centers, ledger accounts, spend categories, locations, etc.).

Workstream impacts

The FDM is a foundational building block of the Workday system. This is evident by how the FDM impacts and integrates itself into other Workday functional areas such as human capital management (HCM) and payroll with cost center configurations, supply change management with location configurations, security with worktag restrictions, and many functions of finance and accounting. Many integrations in other business functions across the Workday environment utilize worktags that are maintained in the FDM and reference the “Reference ID” that is established as the unique identifier. Other functional areas will often use the FDM as their source for obtaining worktag relationships, worktag configuration, etc. to use in their function. Examples include locations that are used for finance and supply chain or bank accounts that are used for banking conversion.

Workday configuration impacts

Account posting rules (APRs) and custom validations (both of which are tenant-level configurations in Workday) define the ruleset that Workday worktags must adhere to for business transactions to be successfully created or posted through data loads or transactions in the Workday environment. These rules include settings like restricting worktags such as spend or revenue categories to specific ledger accounts or requiring a bank account worktag to be used with cash accounts. They can be toggled on and off to allow or push through data during summary conversion scenarios where the ruleset might not be required. The role the FDM plays in these Workday configurations in some scenarios is to separately track which worktags can be mapped or used with other elements. Providing this type of detail might come in the form of organizing worktags with the specific general ledger account that they can be used with or specifying it in a separate column. Cost centers typically have a “restricted to company” column in the FDM to identify the company with which they can be used.

FDM change management

Changes made to the FDM in Workday tenants should be validated utilizing Workday report exports to ensure the completeness and accuracy of the changes being made to the system. This will also detect any unapproved or erroneous changes made by other parties. A good practice to establish when performing this step is to build out validation templates using the report extracts from Workday in conjunction with the FDM workbook, and to write automated formulas that allow for a copy and paste approach with the Workday exports whenever changes are made in the system. A combination of VLOOKUPs/XLOOKUPs, concatenations, text functions, if-statements, etc., might be used to compare data returning from the system via Workday report extracts and the FDM. It is crucial to build a repeatable validation process as they may need to be performed many times with updated sets of data.

Maintaining the FDM can be challenging in complex client ecosystems. It is best practice to cross-validate or synch the FDM and the primary GL conversion Workday tenant(s) to ensure worktag and mapping accuracy between the Workday and FDM environments as early as feasible. Accuracy between the FDM and the primary GL conversion Workday tenant(s) is important for multiple reasons, but most importantly enables quick and concise validations to support fast turnaround times. These cross-validations also help avoid confusion due to contrasting worktag build and worktag mappings between Workday and the FDM data repository maintained offline. An out-of-sync FDM data file:Workday relationship might cause errors in other workstream conversions or daily tasks like within HCM, payroll or supply chain.

Cornerstone of Workday financial processing and reporting

The Workday FDM is the cornerstone of Workday financial processing and reporting with direct impacts to transaction processing, security and access within Workday and the ability to analyze data and transactions effectively. Organizations must give careful thought to how the Workday FDM is designed, developed and maintained to preserve data integrity and long-term system stability. It is not enough to design and maintain the FDM appropriately during the initial implementation. It is equally important to set up a framework to manage and govern updates to the Workday FDM on an ongoing basis to optimize benefits from the Workday system to your financial reporting and planning processes.

Jerine Hu and Graham Wigle also contributed to this post.

To learn more about our Workday consulting services, contact us.