Category: Workday for Finance

Connecting Workday Financials, End to End
Connecting Workday Financials to the rest of your enterprise is not optional. GL needs to talk to legacy ERPs and data warehouses, banks must receive payment files and send statements back, and payroll providers need accurate data and return pay results. Workday’s Integration Cloud, Cloud Connect packages and reporting layer are built to support this, but success depends on using the right patterns for each area: GL, Banking and Payroll.

This guide walks through proven integration patterns that Workday practitioners rely on to keep financial data flowing cleanly across the enterprise.

Foundation: Workday Integration Cloud and FDM

Before diving into patterns, two foundational pieces matter:
- Workday Integration Cloud
  - Provides tools like EIB, Core Connectors, Cloud Connect packages and APIs to integrate with third‑party systems without additional middleware.
- Foundation Data Model (FDM)
  - Your FDM (Companies, Worktags, hierarchies) is the common language GL, banking and payroll integrations should share.
  - If FDM is inconsistent or poorly designed, integrations will continuously require mapping and manual fixes.
Good integration design assumes a stable FDM and uses Workday’s native integration capabilities where possible instead of custom point solutions.

GL integration patterns: feeding analytics and other ERPs

Even when Workday is the system of record for finance, other systems often need GL data: data warehouses, planning tools, legacy ERPs or industry solutions.

Proven GL patterns:
1. Outbound GL summaries to data warehouse/BI
  - Use report‑based outbound integrations or EIBs to export GL journals or balances by ledger, account and Worktags on a daily or intraday schedule.
  - Keep extracts based on Approved/Posted journals only to avoid half‑baked data.
2. Trial balance feeds to legacy ERPs or consolidation tools
  - For transitional periods, export trial balance or chart-of-accounts‑mapped outputs from Workday to legacy tools until full decommission.
  - Stabilize mapping between Workday accounts/Worktags and external dimensions; do not change it lightly.
3. FP&A / planning integration
  - For Workday Adaptive Planning, use native connectors; for other FP&A tools, publish GL and Worktag data via secure outbound integrations.
Key practices:
- Use a small number of standardized GL feeds (for example, one for detailed journals, one for balances) instead of many custom variations per consumer.
- Drive filters and time windows from Workday effective dates and accounting periods so external systems can easily reconcile to Workday financial statements.
The GL integration goal is to ensure every system that needs financial data sees a consistent view aligned with Workday.

Banking integration patterns: payments and bank connectivity

Bank connectivity has two main flows: outbound payments and inbound bank statements. Workday Financial Management supports both through its bank connectivity features and integration cloud.

Outbound to banks:
- Payment file integrations
  - Use Workday’s Bank Connectivity and payment formats (ACH, SEPA, wire formats) to send payment files directly to banks or via treasury platforms.
  - Payment runs (settlements) generate files including bank account, amount, remittance info and typically use SFTP or bank APIs for transmission.
- Standard patterns
  - One integration per bank or per channel (for example, “US‑BOA‑ACH”, “EU‑SEPA”) rather than per business unit.
  - Use Workday’s payment formats where possible instead of fully custom layouts to reduce maintenance.
Inbound from banks:
- Bank statement imports
  - Import BAI2, MT940 or other formats into Workday’s banking module on a daily or intraday basis for reconciliation.
  - Use automated integrations (SFTP/API) so statement loading does not depend on manual uploads.
- Reconciliation integration
  - Workday’s reconciliation rules match bank lines to internal transactions (AP, AR, Payroll, journals). Clean integration plus good matching rules gives near real‑time cash visibility.
Best practices:
- Centralize Bank Account Management (owners, formats, security) and treat bank integrations as high‑risk, high‑control elements.
- Standardize remittance and statement reference fields so matching and cash positioning work reliably in Workday.
These patterns turn Workday into the hub of your banking flows rather than just another system generating flat files.

Payroll integration patterns: global payroll via Cloud Connect

For payroll, many organizations use Workday HCM + Workday Financials + third‑party payroll providers. Workday’s Cloud Connect for Third‑Party Payroll and Global Payroll Partner network provide predefined patterns.

Core patterns:
1. Outbound HR and time data to payroll
  - Use Workday Cloud Connect for Third‑Party Payroll (TPP) or Global Payroll Connect (GPC) to send worker data, compensation, time, absence and costing information to payroll providers.
  - These connectors support effective‑dated change extraction (for example, using PECI) so all events in a pay period are captured.
2. Inbound payroll results to Workday
  - Import payroll results—gross to net, taxes, employer costs—back into Workday to feed GL postings, Costing and Payroll journals.
  - Some partners (for example, CloudPay) support bi‑directional integration with scheduled data transfers.
3. GL and costing integration
  - Leverage standardized payroll costing and posting rules so payroll results integrate seamlessly into Workday’s GL with proper Worktags.
Why Cloud Connect matters:
- Workday’s Payroll Effective Change Interface (PECI) and related connectors deliver effective‑dated event sequences, simplifying integration logic and ensuring payroll sees every change in the right order.
- Certified Global Payroll Partners reduce custom mapping effort and bring prebuilt templates for major countries.
The pattern to aim for is simple: Workday HCM is the system of record for people data; payroll systems are engines; Workday Financials remains the system of record for payroll accounting.

Architectural tips: pattern choices, not one-offs

When designing integrations, think in patterns rather than point solutions:
- Use configurable connectors before custom
  - Prefer Cloud Connect (for payroll, banks, tax providers) and Core Connectors where they exist instead of building every integration from scratch.
- Standardize event vs snapshot
  - For GL and analytics, snapshot/balance feeds often work best.
  - For payroll and worker data, event‑based feeds (effective‑dated sequences) ensure accuracy.
- Secure and monitor everything
  - Use Workday’s integration monitoring and logging to track status, errors and runtime for financial and payroll interfaces.
  - Treat GL, banking and payroll integrations as SOX/ICFR‑relevant and include them in your control framework.
- Keep an integration inventory and roadmap
  - Document purpose, frequency, data domains and owners for each integration.
  - Use that inventory to rationalize overlapping feeds and plan future changes (for example, decommissioning legacy ERPs as Workday adoption grows).
Done this way, “connecting Workday Financials to the rest of the enterprise” stops being a series of one‑off projects and becomes a coherent integration architecture: GL feeds powering analytics, bank connectivity enabling real-time cash, and payroll integrations keeping people and pay in sync across countries.
February 19, 2026
Protecting the Books in Workday
Protecting “the books” in Workday is about more than turning on security. It is about designing Finance security, Segregation of Duties (SoD) and approval controls so that no single person can manipulate critical transactions end‑to‑end, while finance teams can still close the books on time. Workday provides a strong internal control framework—role-based security, domain policies, business process security and audit capabilities—but the value comes from how they are combined.

This guide walks through practical patterns Workday practitioners use to protect financial data without locking down the system.

Understand the Workday security model for finance

Workday security has three main layers that matter for finance:
- Security Groups and Roles
  - Role-Based Security Groups (RBSGs): group users by role (for example, AP Specialist, GL Accountant, Cash Manager, Financial Analyst).
  - User-Based Security Groups: for specific high‑privilege users (for example, Workday Finance Admin).
  - These groups determine who can access which data and tasks.
- Domain Security Policies
  - Control access (view, modify, report, integration) to data domains like Journals, Supplier Invoices, Banking, Revenue, Assets.
  - Govern what data users can see and change—core for protecting the books.
- Business Process Security Policies
  - Control who can initiate, approve, review and cancel steps in financial processes such as Create Supplier Invoice, Create Journal, Bank Settlement, Asset Disposal.
Together, these determine who can do what, to which data, and in which process steps. Designing them intentionally is what keeps financial controls strong.

Build segregation of duties into the model

Segregation of Duties (SoD) is about ensuring no single user can both initiate and complete high‑risk financial activities (for example, create a supplier and pay them, or create a journal and post it).

Key SoD principles for Workday Finance:
- Separate setup from execution
  - Different roles for configuring Suppliers vs processing Supplier Invoices.
  - Separate bank account maintenance from payment processing.
- Separate initiation from approval
  - The person who creates a journal, invoice, payment or asset disposal should not be the only person who can approve or post it.
- Limit “super user” roles
  - Avoid giving broad finance admin roles to many users. Restrict them to a very small, monitored group.
Practical steps:
- Define a SoD rule set for finance that lists incompatible duties (for example, “Create Supplier” + “Approve Payment”, “Create Journal” + “Approve Journal”).
- Map those rules to Workday security groups and business process roles to ensure no single user holds conflicting roles.
- Use tools (Workday reports or marketplace/partner apps) to continuously scan for SoD conflicts in assignments.
SoD should be a design constraint from the beginning, not a cleanup exercise after go‑live.

Approval controls: business processes that actually protect value

Workday’s Business Processes are where you embed practical approval controls for finance. The aim is to design workflows that:
- Enforce SoD (no self‑approval of high‑risk steps).
- Provide visibility to the right stakeholders.
- Do not create unnecessary bottlenecks.
Examples:
- Supplier Invoices
  - Initiation by AP or employees (for invoice requests).
  - Approval by cost center managers or project owners based on Worktags and thresholds.
  - Optional second-level approval for invoices over certain amounts or for sensitive Spend Categories.
- Journals
  - Initiation by GL Accountants or specific business units.
  - Approval and posting by a different user or by Controllers based on amount or account type.
- Bank Payments / Settlements
  - Payment runs initiated by AP or Treasury.
  - Approval of payment batches by authorized signers, potentially with dual approval for large batches.
Design tips:
- Configure conditional steps so approvals vary by company, region, threshold or Worktag (for example, certain Spend Categories always require Finance review).
- Use routing rules to avoid initiators approving their own high‑risk actions.
- Keep the number of approval steps minimal but meaningful; too many steps encourage pressure to bypass controls.
Approved business process histories become part of your audit trail, so they are as much a control as domain security.

Use tools and automation for SoD and control monitoring

Given how dynamic Workday roles and organizations can be, manual SoD monitoring quickly becomes unsustainable. Many organizations use:
- Workday’s own reporting and audit tools
  - Custom reports to analyze domain and business process security assignments against SoD rules.
  - Dashboards to visualize high‑risk access, recent changes and audit findings.
- Marketplace and partner solutions
  - SoD and sensitive access apps in Workday Marketplace (for example, Segregation of Duties and Sensitive Access solutions) to detect conflicting access.
  - Partner tools like PwC, KPMG, Pathlock or Kainos to automate risk analysis, rulesets and continuous monitoring.
Best practices:
- Run SoD analysis after major org or role changes, not just annually.
- Document and approve exceptions (for example, in small entities) with compensating controls like extra approvals or post‑transaction review.
- Include SoD and finance security in your internal audit plan and test it regularly.
Automation reduces the risk that quietly accumulating access conflicts undermine your internal control environment.

Make security and controls usable for finance

Controls fail when they fight day‑to‑day work. To avoid this:
- Design with finance users in the room
  - Involve Controllers, AP, AR, Treasury and FP&A in shaping roles and approvals so they match reality.
- Keep roles meaningful and comprehensible
  - Use clear naming for finance roles (for example, “AP Specialist – US”, “GL Accountant – EMEA”) instead of generic names that confuse ownership.
- Train on “why,” not just “how”
  - Explain to finance teams how security groups, SoD and approvals protect them and the organization (fraud prevention, audit readiness, reputation).
  - Show how to read business process histories and audit logs when investigating issues.
When finance understands and supports the control design, “no access” becomes a signal to fix role design, not to bypass the system.

Protecting the books in Workday is ultimately about balance: designing Finance security, SoD and approval controls robust enough to satisfy auditors and regulators, but streamlined enough that month‑end still closes on schedule. When roles, domains, business processes and monitoring work together, Workday turns into a controlled, transparent platform where financial integrity is built into every transaction.
February 17, 2026
Banking and Cash in Workday, Without Chaos
If banking and cash are messy in Workday, you feel it every single day: duplicate bank accounts, unclear payment statuses, painful reconciliations and no single, trusted view of cash. Workday Cash Management and Banking & Settlement are designed to do the opposite: centralize bank accounts, standardize settlements, and give treasury real-time cash positioning across all entities.

A clean design is less about clever configuration and more about simple, disciplined patterns. The goal: every outgoing payment and incoming receipt is traceable from Workday to the bank statement and back, and your cash position is obvious, not a guessing game.

Step 1: Treat bank accounts as master data, not “just details”

In Workday, Bank Accounts are first‑class configuration objects, not just text fields on payments.

Key ideas:
- Maintain a central register of bank accounts used for payments, receipts and working funds.
- For each account, capture: bank, branch, account number/IBAN, currency, owning Company, and which settlement types it supports (AP, Payroll, Customer Receipts, Misc).
- Use clear naming so users can distinguish accounts in the UI (for example, “US‑BOA‑AP‑USD”, “EU‑HSBC‑AP‑EUR”, “US‑BOA‑PAYROLL‑USD”).
Good practices:
- Minimize the number of operational bank accounts to reduce reconciliation workload and fraud risk. Many Workday customers consolidate AP accounts as part of their implementation.
- Restrict who can create or change bank accounts; treat them like sensitive master data with proper approvals.
- Configure which Payment Types can use each bank account (checks, ACH, wires, SEPA, etc.) so users cannot accidentally route the wrong payments through the wrong account.
When bank accounts are clean and governed, everything else—settlements, reconciliations, cash views—becomes more predictable.

Step 2: Understand how settlements tie subledgers to cash

Workday’s Settlement engine sits between subledgers (AP, AR, Payroll, Expenses) and your bank accounts. It groups transactions, triggers payments, and produces the items you reconcile.

Core concepts:
- Settlement Runs (or payment runs) pick up eligible items (supplier invoices, expense reports, customer refunds, etc.) and create payment instructions against a specific bank account.
- Settlement Types and Payment Formats control how Workday talks to the bank (files like ACH, SEPA, BAI2, MT940, or APIs).
- Each settled batch becomes a set of entries that update cash and clearing accounts in the ledger.
Patterns that keep things orderly:
- Align settlement runs with your operational rhythms:
  - For example, AP: twice weekly; Payroll: per pay cycle; Misc payments: weekly.
- Use clear naming and scheduling for settlement jobs (e.g., “US‑AP‑ACH‑Mon/Wed”, “EU‑AP‑SEPA‑Tue/Thu”), so finance and treasury know what to expect each day.
- Make sure each bank account is associated with the right Settlement Types only; do not let one account handle everything unless absolutely necessary.
This discipline means that when you see a payment on the bank statement, you can quickly identify which settlement run and Workday transactions it came from.

Step 3: Bank reconciliation without the spreadsheet circus

Workday’s Bank Account Reconciliation and Cash Management apps are where you prove that Workday’s view of cash matches the bank’s.

Typical process:
1. Import bank statements
  - Use Import Bank Statement to load files (BAI2, MT940, or bank-specific formats) from your banks into Workday.
  - Automate this via secure integration where possible so statements arrive daily or intra‑day.
2. Auto-match transactions
  - Use the reconciliation rules engine to automatically match bank lines to Workday settlements and ad hoc bank transactions based on amount, date, reference and other fields.
  - Define matching rules that prioritize high-confidence matches and leave edge cases for manual review.
3. Manual match and adjustments
  - For unmatched items, use Match Bank Transactions or similar tasks to link bank lines to Workday items, or create Ad Hoc Bank Transactions for bank-only items (fees, interest).
  - Use Bank Adjustment tasks for corrections (for example, bank fees, returned checks).
4. Finalize reconciliation
  - Once differences are resolved, mark the reconciliation as complete and generate reconciliation reports for audit.
Best practices:
- Reconcile high‑volume, high‑risk accounts (AP, Payroll, sweeping accounts) daily or at least several times per week.
- Keep matching rules simple at first; tune them based on real exceptions rather than trying to solve every scenario on day one.
- Regularly review recurring unmatched items; they often signal configuration or process issues upstream.
When reconciliation is embedded in Workday, spreadsheets become the exception, not the default.

Step 4: Cash positioning that treasury actually trusts

The payoff of all this is reliable cash positioning: a real-time view of cash balances and expected movements across all bank accounts and companies.

Key features:
- Cash Position reports show current balances by bank account, bank, currency and company, pulling from reconciled and in‑flight transactions.
- Cash Forecasting uses scheduled settlements, customer receipts and other expected flows to project future cash positions.
To make these views credible:
- Ensure that all bank accounts used for payments and receipts are represented and kept in sync with your actual banking landscape.
- Keep statement imports and reconciliations timely so “current balance” really means current.
- Include both settled payments and pending runs (for example, upcoming payroll) in your internal cash views where needed.
Finance and treasury can then answer questions like:
- “What is our cash by company and currency today?”
- “Do we have enough cash in EUR accounts to cover Thursday’s settlements?”
- “Which accounts should we sweep or fund?”
The more your processes consistently use Workday’s settlement and reconciliation capabilities, the more accurate your cash position becomes.

Step 5: Governance to keep banking and cash from drifting

Banking and cash configuration is high‑risk and high‑impact, so treat it with strong governance.

Practical guardrails:
- Segregate duties
  - Separate configuration of bank accounts, initiation of settlement runs and approval of payments where possible.
  - Restrict who can change bank account details and reconciliation rules.
- Standardize processes
  - Document which settlement jobs run when, which team monitors them, and what to do in case of failures.
  - Keep a simple runbook for bank reconciliation and cash reporting, especially for month-end.
- Monitor and improve
  - Track metrics such as percentage of auto-matched bank lines, time to complete reconciliations, and frequency of bank-related journal corrections.
  - Use these as feedback to refine matching rules, posting rules or upstream processes.
When Bank Accounts, Settlements and Cash Positioning are designed together rather than in silos, Workday becomes the place where you actually run banking and cash—not just record it after the fact. Treasury gets real visibility, finance gets clean reconciliations, and everyone spends less time chasing unexplained bank lines.
January 29, 2026
Contract-to-Cash in Workday, Done Right
Contract‑to‑cash in Workday lives primarily in Workday Revenue Management and Customer Contracts. The goal is simple: capture contract terms once, then let Workday automate billing and revenue recognition in a way that is compliant with standards like ASC 606 / IFRS 15 and understandable to Finance and audit. When the design is weak, you see manual invoices, spreadsheets for revenue schedules and constant reconciliations. When it is strong, quotes from CRM become contracts, contracts become billing schedules, and revenue flows without surprises.

This guide walks through how to think about Revenue Contracts, Billing Schedules and Revenue Recognition so contract‑to‑cash actually works end to end.

Step 1: Understand the core contract-to-cash objects

Before configuring anything, clarify the key objects in Workday Revenue Management:
- Customer – the party you invoice and recognize revenue from.
- Customer Contract – the central record of what you have sold, for how much, and over what period. It can contain multiple Contract Lines.
- Contract Line – a specific promised good or service (for example, annual subscription, implementation services, usage-based fees).
- Billing Schedule – defines when and how much to bill under each Contract Line.
- Revenue Recognition Schedule – defines when and how much revenue to recognize under each Contract Line, often separate from billing.
Think of the Customer Contract as the “single source of truth” for both billing and revenue. It links CRM/quote data to GL outcomes through automation.

Step 2: Design Customer Contracts that reflect real products and services

Your Customer Contract structure should reflect how you actually sell.

Design considerations:
- Contract types
  - Subscriptions or SaaS.
  - Time & materials or milestone‑based services.
  - Fixed‑fee projects.
  - Usage‑based or consumption contracts.
- Contract line setup
  - Use one Contract Line per distinct performance obligation (for example, “Year 1 Subscription”, “Implementation Services”, “Premium Support”).
  - Attach the right Revenue Category, Worktags (Customer, Project, Cost Center, Region) and any necessary attributes for pricing and accounting.
- Integration with CRM
  - For many organizations, CRM (often Salesforce) drives quotes and orders that feed Workday as Customer Contracts. Set clear mapping between products in CRM and Contract Lines in Workday.
Good patterns:
- Keep contract lines granular enough to support different billing and revenue patterns, but not so granular that you create unmanageable volume.
- Capture key dates (contract start, end, renewal) and terms (billing frequency, discounting, one‑time vs recurring) as structured fields rather than free text.
A well-designed contract structure is the foundation for clean billing and revenue rules.

Step 3: Build billing schedules that match cash realities

Billing Schedules turn contract lines into invoices. They answer “when do we send invoices and for how much?”

Common billing patterns:
- Upfront / prepaid – bill full or partial contract value at the start.
- Periodic – monthly, quarterly or annual recurring invoices for the duration of the contract.
- Milestone‑based – invoices triggered when milestones or events are reached.
- Usage‑based – billing based on actual consumption (for example, units, transactions, hours).
In Workday:
- You configure billing schedules at the Contract Line level, often using templates or schedule types (for example, “Standard Monthly”).
- Workday generates Customer Invoices according to the schedule and posts them to AR and the GL when approved.
Best practices:
- Align billing schedules with your cash flow strategy and customer expectations: for example, annual upfront billing for subscriptions vs milestones for implementation.
- Use standard schedule types wherever possible (e.g., monthly, quarterly) to minimize custom schedule noise.
- Ensure invoices generated from billing schedules clearly reference the contract and lines so collections and reporting stay aligned.
Billing schedules are about cash—but they are not the same as revenue.

Step 4: Separate billing from revenue with robust recognition schedules

Accounting standards like ASC 606 and IFRS 15 require that revenue be recognized when performance obligations are satisfied, not necessarily when cash is billed or collected.

Workday supports this through Revenue Recognition Schedules:
- Configured per Contract Line (or group of lines) to define how revenue is spread over time or events.
- Can be time‑based (for example, straight-line monthly over the contract term) or event/usage‑based (for example, when services are delivered or usage occurs).
Recognition schedule patterns:
- Subscription / SaaS – often straight-line revenue over the service period, even if billed upfront.
- Implementation services – revenue tied to milestones, timesheets, or percent complete.
- Usage‑based – revenue recognized according to usage transactions (for example, units consumed).
In Workday:
- Use the Create Revenue Recognition Schedule for Customer Contracts process to generate schedules for contract lines according to a chosen template (e.g., standard monthly).
- Workday generates revenue recognition installments that post to the GL, moving amounts from Deferred Revenue to Revenue.
Critical point: Billing schedules drive AR and cash; revenue schedules drive the P&L. They must be linked but not identical.

Step 5: Automate allocation and multi-element arrangements

Many contracts bundle multiple performance obligations (for example, software license, implementation, and support) with a single price. Workday supports revenue allocation across Contract Lines to comply with standalone selling price guidance.

Capabilities:
- Allocate contract consideration across multiple Contract Lines based on their standalone selling prices or relative values.
- Adjust revenue schedules per line while leaving billing schedules as agreed with the customer.
Usage:
- For bundled deals, set each performance obligation as a separate Contract Line with its own revenue rules.
- Use Workday’s allocation tools to spread total contract price across lines in a compliant way.
This allows, for example, more revenue to be allocated to implementation early and less to subscription, even if billing is flat or front‑loaded.

Step 6: Integrate contract-to-cash with projects and AR

Contract‑to‑cash does not live in isolation:
- Projects – For services and billable projects, link Projects/Tasks to Contract Lines so time, expenses and costs drive billing and revenue.
- Accounts Receivable – Customer Invoices from billing schedules flow into AR for collections, dunning and cash application.
- General Ledger – Revenue and deferred revenue postings flow into the ledger with proper Revenue Categories and Worktags (Customer, Region, Product, etc.).
Best practices:
- Make sure Customer Contracts, Projects and Customers are consistently tagged with key Worktags (Sales Region, Product Line, Segment) to support management reporting.
- Ensure AR and Revenue teams share a view of contract statuses, invoice schedules and revenue schedules to coordinate on modifications and renewals.
This integrated view turns Workday into a genuine contract‑to‑cash platform rather than just a billing tool.

Step 7: Governance, modifications and renewals

Customer contracts evolve—renewals, upsells, partial terminations, scope changes. Your design must handle contract modifications cleanly.

Governance points:
- Use consistent processes for amendments—new Contract Lines vs modifying existing ones vs creating new contracts for expansions.
- Understand how modifications should be treated under your revenue policies (prospective, retrospective, or blended).
- Maintain audit trails: Workday tracks contract versions, approvals and schedule changes; align this with your internal SOX/ICFR controls.
Reporting and controls:
- Monitor reports on Contracted vs Billed vs Recognized amounts per contract and per portfolio.
- Use exception reports to find contracts with no active revenue schedule, unusual allocation patterns or missing billing schedules.
When governance around contracts, billing schedules and revenue recognition is strong, finance and audit trust the system’s numbers and can trace every P&L impact back to a contract line.
January 28, 2026
Workday Financials for Non-Tech Finance
Opening Workday Financials for the first time can feel like stepping into a new language. You see Company, Entity, Ledger, Worktag, Cost Center and wonder how it all ties back to your familiar trial balance and P&L. The good news: once you understand a few core concepts – entities, ledgers and worktags – Workday becomes a very friendly system for non-technical finance users.

This tour explains those building blocks using plain finance language, so you can confidently review journals, approvals and reports without needing to be a Workday expert.

Entities: who’s doing the accounting?

In Workday, an Entity (often surfaced as Company or Company/Entity) represents the legal or accounting unit where transactions post and financial statements are produced.

As a finance user, think of entities as:
- The companies or legal entities you already know from your statutory books.
- The units you produce balance sheets, P&Ls and trial balances for.
- The basis for intercompany relationships and consolidation.
Key points:
- Every financial transaction in Workday – supplier invoice, customer invoice, expense report, journal – belongs to an Entity.
- Entities drive things like functional currency, fiscal calendar and consolidation rules.
- When you see questions like “Which company is this invoice for?” in Workday, that maps to entity selection.
If you understand which entities exist in your group today, you are already halfway to understanding the Workday structure.

Ledgers: where transactions land

The Ledger is the place where accounting entries are recorded and balanced. In Workday, you may see Primary Ledger, Adjustment Ledgers, and specific ledger scenarios for local or management reporting.

For non-technical users:
- The Primary Ledger holds your main accounting entries for each entity.
- Additional ledgers can be used for adjustments, local GAAP vs group GAAP, or other management views.
Day to day, you will see ledgers in:
- Journals – each journal posts to a specific ledger and period.
- Reports – you can filter or run P&Ls and balance sheets by ledger if you have multiple.
You do not need to configure ledgers, but knowing which ledger a report uses helps you interpret if numbers are statutory, management, or adjustment-inclusive.

Worktags: Workday’s replacement for long account strings

The biggest conceptual shift in Workday Financials is Worktags. Instead of long account strings (Company-Department-Account-Project…), Workday attaches multiple Worktags as labels to each transaction.

Worktags are:
- Short labels that describe the “who, what, where, why” of a transaction.
- Used for routing approvals, posting entries and reporting.
Common Worktags include:
- Cost Center – which department or unit owns the cost.
- Fund / Program / Grant / Project / Gift – funding or project dimensions (often called Driver Worktags).
- Spend Category / Revenue Category – what you are buying or what income you are recognizing (similar to account/object codes).
- Location – where the cost or revenue occurs (office, store, plant).
- Assignee – who the cost is related to (for example, an employee for chargebacks).
In practice:
- Every requisition, invoice, expense report and journal uses Worktags instead of a single long code.
- One Driver Worktag (like Project or Cost Center) often auto-populates other Related Worktags, making entry easier and more consistent.
As a non-technical finance user, your job is usually to:
- Check that the Cost Center and Spend/Revenue Category are correct.
- Confirm the Project/Grant/Program if relevant.
- Make sure the Worktags match how you want to see the spend in reports.
How entities, ledgers and worktags meet in a transaction

Consider a simple supplier invoice in Workday:
- You select the Company/Entity – this determines which legal entity is booking the expense.
- The invoice lines use Worktags such as Cost Center, Spend Category, Project and Location.
- When the invoice is posted, Workday uses its accounting rules to create ledger entries in the correct Ledger with the right accounts and dimensions.
Behind the scenes:
- Accounting Rules map Worktag combinations (for example, Entity + Spend Category) to ledger accounts.
- Worktags determine routing (who approves), reporting (which department sees the cost) and analytics.
From your perspective, you can review an invoice and quickly answer:
- “Is this hitting the right company?” (Entity)
- “Is it going to the right department or project?” (Cost Center / Project Worktags)
- “Is the type of spend coded correctly?” (Spend Category)
Once you are comfortable “reading” a Workday transaction like this, reviews and approvals become much easier.

Worktags in reports: how finance actually uses them

Worktags are not just data entry fields; they are the backbone of Workday financial reporting.

Typical reports you will use:
- Trial balance and P&L by Worktag – for example, P&L by Cost Center, by Program, by Project.
- Spend by Worktag – spend by Supplier and Spend Category, or by Project and Cost Center.
- Budget vs actual – combining Worktags used in budgets and actuals to show variances.
Benefits for non-technical users:
- You can easily slice data without needing custom cubes or extra tools.
- Approvers can drill from a summary P&L down to individual transactions and see all Worktags on each line.
- Audit and compliance checks are easier because every transaction carries clear labels.
If reports do not look right, it is often a Worktag issue (wrong Cost Center or Spend Category) rather than a ledger problem.

Tips for non-technical finance users to get comfortable fast

To become fluent in Workday Financials without becoming technical:
- Learn your standard Worktag sets
  - For example, which Cost Centers you support, common Spend Categories, and key Projects or Grants.
  - Keep a simple cheat sheet for your area.
- Practice reading journals and invoices
  - Open a few recent transactions and inspect the Worktags and ledger entries.
  - Verify that they align with how you would have coded them in your old system.
- Use Workday reports and drill-downs
  - Start with delivered or standard reports for trial balance, P&L and spend reports.
  - Use drill-down to go from high-level numbers to underlying Worktag detail.
- Ask where Worktags are auto-populated
  - Many Worktags default from the worker, cost center or project. Understanding these defaults reduces manual corrections.
You do not need to know every configuration detail; you just need to know how Entities, Ledgers and Worktags show up in your day-to-day screens and reports.

Once those three pieces click, Workday stops feeling like a complex system and starts feeling like a flexible, label-based accounting tool that supports the way finance actually thinks about the business.
November 28, 2025
Project Accounting in Workday, Step by Step
Project Accounting

Project accounting in Workday is not just a “Finance feature.” It is the thread that connects Projects, Worktags, Time Tracking, Expenses, Procurement and Billing into a single picture of project cost, margin and progress. When you design it intentionally, you can see exactly what each project costs, what to invoice, and how profitable it is—without extracting everything to spreadsheets.

This guide walks step by step from project setup to employee expenses, using Workday terminology throughout.

Step 1: Design your project Worktag model

In Workday, Project itself is a Worktag, usually a Driver Worktag. When added to a transaction line, it can auto-populate related Worktags such as Cost Center, Program, or Grant via Related Worktags.

Decisions to make up front:
- What types of projects will you track?
  - Customer / billable projects (client work, external funding).
  - Internal / administrative projects (internal initiatives, overhead).
  - Capital projects (fixed asset construction, IT implementations).
- Which Worktags should be tied to Project?
  - Cost Center, Program, Fund/Grant, Region, maybe a Custom Worktag for Portfolio or Product Line.
Design patterns:
- Use a clear naming convention for Projects: prefix by project type or business line (e.g., “CUST‑1001 – Client A ERP”, “CAP‑2003 – HQ Renovation”).
- Configure Project Allowed Worktags so only valid Worktag combinations can be used with each Project (for example, only certain Cost Centers or Funds).
- Build project hierarchies where you need rollups (programs or portfolios) using Project Hierarchies and related structures.
A good Worktag design means you do not have to teach users every rule; Workday enforces a lot of it for you.

Step 2: Create projects with the right attributes

The Create Project process in Workday captures core data and determines how the project behaves in financials, expenses and billing.

Key fields and decisions:
- Project Type – Administrative, Customer, Capital, etc. This drives downstream behavior, including capitalization and billing options.
- Owning Company / Entity – which legal entity owns the project and will recognize revenue/cost.
- Worktags – Cost Center, Program, Customer (for customer projects), Location, and any Custom Worktags.
- Billable vs Non‑billable – indicates whether costs should be available for billing and margin analysis.
- Project Plan / Tasks – optional but powerful: break the project into tasks or work packages to track cost and progress at a more detailed level.
Best practices:
- Use template projects for common patterns (for example, standard professional services engagements) to default Worktags, billing settings and tasks.
- Capture Customer and Contract/Billing references at project setup for billable projects to avoid reconciling later.
- For capital projects, confirm how costs will later link to Assets and Capitalization processes.
Once created, the Project becomes the central Worktag used across time, expenses, procurement and journals.

Step 3: Capture time and expenses against projects

To see true project cost, you must push Time Tracking and Expenses through the project lens. Workday Projects ties into both modules.

Time:
- Configure Time Entry Templates and Time Entry Codes so workers can select a Project (and optionally Task) on their time entries.
- Use Work Type Rules to classify time (e.g., billable vs non‑billable, standard vs overtime) for project cost and revenue.
- Make sure time approvals align with project responsibility—line managers or project managers, depending on your operating model.
Expenses:
- Enable Project as a Worktag on Expense Reports so employees can charge travel, materials and other charges directly to projects.
- Configure Expense Item defaults to automatically set Spend Categories and some Worktags, leaving employees to choose only Project (and maybe a Task).
- Set up expense approval hierarchies that route project‑coded expenses to the right project or cost center owner.
By getting time and expenses to consistently carry the Project Worktag, you build a clean cost view without manual allocation journals later.

Step 4: Capture procurement and AP costs to projects

Project costs often come through procurement: purchase orders, supplier invoices and sometimes journals. Workday enables project tagging across these flows.

Patterns:
- On Purchase Requisitions and Purchase Orders, include Project and related Worktags on lines that are project-specific.
- For Supplier Invoices, either inherit the Project from the PO or allow AP to add Project Worktags directly on invoice lines where appropriate.
- Use Project Allowed Worktags rules to prevent invalid combinations (e.g., wrong Cost Center or Fund for that project).
Capital projects:
- Ensure procurement and AP spend for capital projects are coded to the capital project and appropriate Spend Categories (e.g., Capitalizable construction or equipment categories).
- Later, Workday can help create Project Assets and move costs from Construction-in-Progress (CIP) to fixed assets.
This approach keeps all project-related spend, not just internal time and expenses, visible at project level.

Step 5: Budgeting and tracking against plan

Project accounting becomes truly useful when you compare actuals to budget or plan.

Options:
- Use Project Budgets:
  - Create project-level budgets with the Project Worktag plus other dimensions like Cost Center and Spend Category.
  - Submit for approval and tie them into your broader financial planning process.
- Use Resource / Project Plans:
  - For services projects, build resource plans to estimate effort and cost by role or worker.
Reporting:
- Build reports and dashboards showing Budget vs Actual by Project, by Task, and by Worktag (e.g., by Spend Category, Cost Center, Customer).
- Include both labor (time, payroll allocations) and non‑labor (supplier, expenses) costs for a full project cost picture.
Good practice is to define who owns the project budget (Project Manager, PMO, Finance) and how often you review project financials—monthly is common for active projects.

Step 6: Billing and revenue for customer projects

For customer projects, project accounting feeds directly into Workday Project Billing and revenue.

Key elements:
- Billing Plans: define how and when you bill (time & materials, fixed fee, milestones, retainers).
- Billing Events and Invoice Generation: Workday converts billable project transactions into customer invoices according to your billing plan and rules.
- Revenue Recognition: revenue schedules and rules determine when revenue is recognized for project work, potentially decoupled from billing.
Make sure:
- Only appropriately tagged billable time and expenses hit billing, based on Work Types or billable flags.
- Contracts, Projects and Customers are linked correctly so invoices automatically reflect the right project, PO, and tax settings.
This ensures your project accounting supports both cost control and the top line.

Step 7: Governance and “project hygiene”

Project accounting can decay over time if governance is missing. Keep it healthy with:
- Project lifecycle rules
  - Clear criteria for moving projects from Open → Active → Closed.
  - Regular reviews to close dormant or completed projects to prevent miscoding.
- Worktag hygiene
  - Regular checks for transactions posted to “wrong” or generic projects requiring reclass.
  - Use reports to identify expenses and invoices without Projects where they should have one.
- Training and quick references
  - Provide Project and Worktag cheat sheets per business area (which Projects to use, which are closed, etc.).
  - Train project managers to use Workday reports and dashboards, not offline trackers, for financial views.
Treat project accounting as a shared responsibility between Finance, PMO and delivery teams.

When you design project accounting in Workday as an integrated process—from Project setup to Time & Expense capture, Procurement, Budgeting and Billing. You end up with a living, accurate view of project performance. Finance gets clean numbers, project managers get real insight, and leadership can see where work is truly profitable.
November 5, 2025

Workday Calculated Fields: Complete Tenant Implementation Guide

Walking into your Workday tenant to create your first calculated field can feel overwhelming. Where do you start? What security do you need? How does the Formula Assistant actually work? This comprehensive guide walks you through exactly how calculated fields are configured, tested, and deployed in a real Workday tenant—from security setup to production activation.

Unlike generic tutorials that show pseudocode, this guide demonstrates the actual Workday tenant interface, real task names, exact navigation paths, security domain configurations, and step-by-step Formula Assistant usage. You’ll learn how Workday administrators actually implement calculated fields in production environments, including security considerations, testing protocols, and maintenance workflows.

Understanding Your Workday Tenant Environment

Before creating calculated fields, understand how your Workday tenant is organized and secured.

Tenant Types and Configuration Environment

Most organizations have multiple Workday tenants:

Implementation Tenant (Sandbox)

Used for configuration, testing, and training
No real employee data (or anonymized data)
Where you build and test all calculated fields first
Typical naming: [CompanyName]_Implementation or [CompanyName]2

Production Tenant

Live system with real employee data
Where employees and managers work daily
Only deploy tested, approved calculated fields here
Typical naming: [CompanyName] or [CompanyName]_Production

Preview Tenant (if applicable)

Optional tenant for testing Workday updates
Gets new Workday features 3-4 weeks early
Used to test calculated fields against upcoming releases

CRITICAL RULE: Always create and test calculated fields in your Implementation/Sandbox tenant first, never directly in Production.

Security Domains: The Foundation of Calculated Field Access

Workday uses security domains to control who can create, edit, view, and use calculated fields.

Custom Field Management Domain

To create system-wide calculated fields, you need access to the Custom Field Management security domain.

What this domain allows:

Create new calculated fields
Edit existing calculated fields
Delete calculated fields
Activate/deactivate calculated fields
View all calculated fields in the tenant

Who should have this access:

Workday Administrators
Senior HCM Implementers
Report Writers (sometimes, depending on organization policy)

Best practice: Limit Custom Field Management domain access to 3-5 key administrators to avoid duplicate fields and maintain consistency.

Private Calculated Fields Management Subdomain

The Private Calculated Fields Management subdomain allows creating report-specific calculated fields.

What this enables:

Create calculated fields that only exist within a single custom report
Useful for one-off calculations not needed system-wide
Doesn’t clutter the global calculated field library

Who typically has this:

Report Writers
Report Administrators
Business analysts creating custom reports

Derived Security: How Calculated Fields Inherit Permissions

Here’s a critical concept many Workday users miss: calculated fields inherit security from their source fields.

Example scenario: You create a calculated field that uses Base Salary (secured to Compensation domain) and Performance Rating (secured to Talent domain).

Who can see calculated field values? Only users who have access to BOTH the Compensation domain AND Talent domain. If a user only has Compensation access, the calculated field returns blank.

Viewing calculated field security:

Open the calculated field in Workday
Click Related Actions → Calculated Field → View Security Groups
Workday displays:
- Underlying secured fields
- Security domains for each field
- Which security groups can access the calculated field

This derived security model ensures calculated fields can’t bypass existing data access controls.

Step-by-Step: Creating a Calculated Field in Your Tenant

Let’s walk through creating an actual calculated field using the real Workday interface.

Real-World Example: Employee Tenure in Months

Business Requirement: Calculate employee tenure in months from hire date to current date for benefits vesting and service awards.

Phase 1: Accessing the Create Calculated Field Task

Method 1: Global Search (Most Common)

Click in the Workday search bar at the top of any page
Type: create calculated
As you type, Workday displays matching tasks
Click on: Create Calculated Field

Pro tip: You can type just the first 3 letters of each word: cre cal and Workday will find the task.

Method 2: Task Navigation (Legacy Method)

Click the Workday menu icon (upper left)
Navigate: System → Custom Fields → Create Calculated Field

Method 3: From Maintain Calculated Fields Report

Search for: Maintain Calculated Fields
Run the report (shows all existing calculated fields)
Scroll to bottom of report
Click: Add New button

The Maintain Calculated Fields report is your control center for managing all calculated fields in your tenant. Bookmark this report for easy access.

Phase 2: The Create Calculated Field Configuration Screen

When you open the Create Calculated Field task, Workday displays the configuration screen with several sections:

Main Configuration Sections:

Field Name – Where you name your calculated field
Business Object – Determines where the field lives (Worker, Position, etc.)
Function – The calculation type you’ll use
Calculation Tab – Where you build your formula
Display Options – How the field appears in reports
Security – View derived security

Phase 3: Configuring the Field Name and Business Object

Field Name Configuration

In the Field Name field, enter:

CF_Worker_Tenure_Months

Workday naming best practices:

Prefix with “CF_” – Makes calculated fields easy to identify in field pickers
Include business object – CF_Worker, CF_Position, CF_Organization
Describe the calculation – Tenure_Months, Total_Compensation, Eligibility_Flag
No spaces – Use underscores: CF_Employee_Tenure not CF Employee Tenure
Max 40 characters – Keep names concise

Examples of good names:

CF_Worker_Tenure_Months ✓
CF_Position_Over_Budget_Flag ✓
CF_Manager_Span_of_Control ✓
CF_Total_Compensation_Currency ✓

Examples of poor names:

Tenure ✗ (no prefix, not descriptive)
CF Employee Tenure Calculation 2024 ✗ (spaces, too long, dated)
My_Custom_Field_1 ✗ (not descriptive)

Business Object Selection

Click the Business Object lookup field. Workday displays a picker with all available business objects.

Most common business objects for HR calculated fields:

Worker – Employee-specific calculations (tenure, compensation, eligibility)
Position – Position-related calculations (budget, headcount, grade)
Organization – Org-level rollups (total headcount, budget utilization)
Job – Job profile calculations (job family groupings)

For our tenure example, select: Worker

CRITICAL: Business object selection cannot be changed after creation. If you select the wrong object, you must delete and recreate the calculated field.

Add Business Description

Scroll down to the Business Description field.

Enter a comprehensive description:

Calculates employee tenure in complete months from original hire date to current date. Used for benefits vesting calculations, service award eligibility, and retention reporting. Returns blank if hire date is null. Updated real-time on every report execution.

What to include in descriptions:

Purpose – What business need does this solve?
Calculation logic – How does it work?
Source fields – What data does it use?
Usage – Where is this used (reports, business processes, integrations)?
Edge cases – How does it handle missing data?
Maintenance notes – Special considerations

Good documentation prevents duplicate calculated fields and helps future administrators understand intent.

Phase 4: Using the Formula Assistant

Now comes the critical part: building your formula using Workday’s Formula Assistant.

Opening the Formula Assistant

Click the Calculation tab at the top of the screen
Look for the Function field
Click the magnifying glass icon next to Function
This opens the Formula Assistant interface

The Formula Assistant is Workday’s graphical formula builder—you don’t write code, you configure formulas through dropdown menus and field pickers.

Selecting Your Function

The Formula Assistant displays Workday’s function library organized by category:

Function Categories:

Date – Date calculations and formatting
Text – String manipulation
Arithmetic – Mathematical operations
Condition – IF/THEN logic
Boolean – True/False conditions
Lookup – Related object traversal
Aggregation – Sum, Count, Average

For tenure calculation:

Scroll to the Date category
Click to expand Date functions
Select: Date Difference
Click OK or Select

Configuring Function Parameters

After selecting Date Difference, the Formula Assistant displays three parameter fields:

Parameter 1: Start Date

This is where you select the beginning date for the calculation
Click the field picker icon (magnifying glass)
A hierarchical field browser opens showing Worker business object fields
Navigate to: Worker → Employment Data → Hire Date
Click to select Hire Date
The Formula Assistant populates: Worker.Hire_Date

Parameter 2: End Date

This is the end date for the calculation
Click the field picker icon
Instead of selecting a field, click Add Function
Select function: Current Date
This function has no parameters—it just returns today’s date
The Formula Assistant shows: Current_Date()

Parameter 3: Return Type

This determines the format of the result
Click the dropdown or type directly
Options: “Days”, “Months”, “Years”
Type: "Months" (include the quotation marks)

Your complete formula now reads:

Date_Difference(Worker.Hire_Date, Current_Date(), "Months")

Formula Syntax Visualization in the Assistant

The Formula Assistant displays your formula in a tree structure:

└── Date_Difference
    ├── Start Date: Worker.Hire_Date
    ├── End Date: Current_Date()
    └── Return Type: "Months"

This visual representation helps you understand the formula hierarchy.

Adding Error Handling

At the bottom of the Formula Assistant, you’ll see a critical checkbox:

☑ Return Blank When Function in Error

Always check this box for production calculated fields.

What this does:

If Worker.Hire_Date is null (missing), the calculated field returns blank instead of causing an error
If any calculation fails, returns blank rather than breaking the report
Prevents report execution failures

When NOT to check this (temporarily):

During initial testing in sandbox
When you want to see specific error messages for debugging
Always enable before production migration

Phase 5: Testing Your Calculated Field

Before activating your calculated field, test it thoroughly.

Built-in Test Functionality

Workday provides a testing interface right in the calculated field configuration screen:

Click the Test button at the bottom of the screen
Workday opens the Test Calculated Field window
Enter test parameters:
- Select Workers: Choose 5-10 workers to test against
- Effective Date: Usually leave as today’s date
Click OK

Workday executes your formula against the selected workers and displays results in a table:

Worker Name	Hire Date	Calculated Result	Expected Result
John Smith	01/15/2020	70 months	70 months ✓
Jane Doe	03/22/2023	21 months	21 months ✓
Bob Johnson	11/30/2015	109 months	109 months ✓
New Hire	12/01/2025	0 months	0 months ✓
Missing Data	(null)	(blank)	(blank) ✓

Creating Diverse Test Scenarios

Select workers representing different data scenarios:

Positive Test Cases:

Recent hire (0-6 months tenure)
Mid-tenure employee (1-5 years)
Long-service employee (10+ years)
Worker hired exactly 1 year ago (12 months)

Edge Cases:

Worker hired today (should show 0 months)
Worker with missing hire date (should show blank)
Terminated worker (calculation should still work)
Contingent worker (may have different hire date field)

Data Quality Issues:

Worker with future hire date (data error)
Worker with hire date before company founded (data error)

Reviewing Test Results

For each test worker, verify:

Calculation accuracy – Does the result match manual calculation?
Null handling – Workers with missing data show blank, not error
Edge case behavior – Extreme values calculate correctly
Performance – Test completes in reasonable time (<5 seconds)

If results are incorrect:

Click Edit Formula
Review your Formula Assistant configuration
Check parameter order and data types
Verify field pickers selected correct fields
Retest after changes

Phase 6: Saving Without Activating

After successful testing, save your calculated field WITHOUT activating it yet:

Click Done to close the Formula Assistant
At the bottom of the Create Calculated Field screen, click: Submit (not “Submit and Activate”)
Workday saves the calculated field in an inactive state

Why save inactive first?

Allows additional testing in real reports
Enables security configuration review
Permits UAT (User Acceptance Testing) before general availability
Prevents untested calculated fields from appearing in all reports immediately

Workday displays a confirmation message:

Calculated Field "CF_Worker_Tenure_Months" has been saved successfully.

Your calculated field now exists in the tenant but isn’t yet available in reports.

Phase 7: Testing in a Real Report

Before activating, test your calculated field in an actual custom report.

Creating a Test Report

Search for: Create Custom Report
Configure the report:
- Report Name: Test - Tenure Calculation
- Business Object: Worker
- Report Type: Advanced
Add Data Source:
- Primary Business Object: Worker
- Add Instances: All Active Workers
Add Columns:
- Worker > Full Name
- Worker > Hire Date
- Worker > CF_Worker_Tenure_Months

Finding your calculated field in the column picker:

Click “Add Column”
In the search field at top, type: CF_Worker
Your calculated field appears in results
Select and add it to the report

Add a Prompt (Optional):
- Prompt Type: Worker
- Allows you to test specific employees
Run the Report:
- Click Run
- Select test workers or run for all active employees
- Review results

Validating Report Results

Review 20-30 rows manually:

Validation checklist:

✓ Tenure months match manual calculation
✓ Recent hires show small numbers (0-12)
✓ Long-service employees show realistic tenure (not 1,000 months)
✓ Blank values only appear where hire date is missing
✓ Report executes in reasonable time (<30 seconds for 100 workers)

Common issues discovered during report testing:

Wrong field was selected (selected Effective Date instead of Hire Date)
Wrong business object (created on Position instead of Worker)
Return type incorrect (showing days instead of months)
Performance issues with large data sets

Phase 8: Activating the Calculated Field

After successful testing, activate your calculated field to make it available system-wide.

Method 1: Activating from Maintain Calculated Fields Report

Search for: Maintain Calculated Fields
Run the report
Find your calculated field: CF_Worker_Tenure_Months
Click the row for your calculated field
From Related Actions menu, select: Calculated Field → Edit
Check the box: ☑ Active
Click Submit

Method 2: Activating from Global Search

Search for: CF_Worker_Tenure_Months
Click on your calculated field
From Related Actions, select: Calculated Field → Edit
Check: ☑ Active
Click Submit

Activation takes effect immediately. The calculated field now appears in:

Custom report field pickers
Advanced report column selectors
Business process conditions
Integration field selections
Dashboards and matrix reports

Phase 9: Verifying System-Wide Availability

After activation, verify the calculated field is accessible.

Test 1: Field Picker Availability

Create or open any custom report on Worker business object
Click “Add Column”
Type: tenure in the search field
Verify CF_Worker_Tenure_Months appears in results

Test 2: Business Process Condition Availability

Open any Worker-based business process
Add a Condition step
Configure condition logic
Field picker should include CF_Worker_Tenure_Months

Test 3: Security Verification

Test with different user roles:

1. Login as Manager role:

Can they see calculated field values for their direct reports?
Do blank values appear where security restricts access?

2. Login as Employee role:

Can they see their own tenure?
Can they see other employees’ tenure (should be blocked)?

3. Login as HR Analyst role:

Can they see all workers’ tenure values?
Do reports execute without errors?

Managing Calculated Fields: The Maintain Calculated Fields Report

The Maintain Calculated Fields report is your calculated fields control center.

Accessing the Report

Search for: Maintain Calculated Fields and run the report.

What the Report Shows

The report displays all calculated fields in your tenant with these columns:

Key Columns:

Calculated Field Name – The field name
Business Object – Where the field lives
Function – The calculation type
Active – ✓ if active, blank if inactive
Reference Count – How many reports/processes use this field
Last Modified – When it was last updated
Modified By – Who made the last change

Report Actions Available

From the Maintain Calculated Fields report, you can:

1. Edit a Calculated Field:

Click on the calculated field row
Related Actions → Calculated Field → Edit
Modify formula, description, or active status
Submit changes

2. View Security:

Click on the calculated field row
Related Actions → Calculated Field → View Security Groups
See underlying secured fields and domains
Identify which security groups can access the field

3. Copy a Calculated Field:

Click on the calculated field row
Related Actions → Calculated Field → Copy
Creates a duplicate you can modify
Useful for creating similar calculated fields

4. Delete a Calculated Field:

Click on the calculated field row
Related Actions → Calculated Field → Delete
WARNING: Only delete if Reference Count = 0
Deleting a calculated field used in reports will break those reports

5. View Usage:

Click on the calculated field row
Related Actions → Calculated Field → View Usage
See which reports, business processes, and integrations use this field
Critical before making changes or deleting

6. Create New Calculated Field:

Scroll to bottom of report
Click Add New button
Opens Create Calculated Field task

Filtering the Maintain Calculated Fields Report

Use report prompts to find specific calculated fields:

Available filters:

Business Object – Show only Worker calculated fields
Active Status – Show only active or only inactive
Calculated Field Name – Search by name (use wildcards: CF_Worker*)
Modified Date – Show recently changed fields
Function Type – Filter by Date, Text, Arithmetic, etc.

Real-World Implementation Scenarios

Let’s walk through complete tenant implementations with actual navigation.

Scenario 1: Total Compensation Calculator

Business Need: Show employees their complete compensation value including base salary, bonus, equity, and benefits.

Step 1: Plan the Calculated Field

Field specifications:

Name: CF_Worker_Total_Compensation_Annual
Business Object: Worker
Function: Arithmetic (addition)
Source Fields Needed:
- Base Salary (Worker > Compensation > Base Salary)
- Target Bonus (Worker > Compensation > Target Bonus Amount)
- Equity Value (Worker > Stock > Annual Equity Value)
- Benefits Cost (Worker > Benefits > Employer Annual Cost)
- Retirement Match (Worker > Retirement > Annual Company Match)

Step 2: Create the Calculated Field

Search: Create Calculated Field
Field Name: CF_Worker_Total_Compensation_Annual
Business Object: Worker
Business Description:

Calculates total annual compensation including base salary, target bonus, equity value, employer benefits cost, and retirement match. Used in Total Rewards statements and compensation analysis reports. Values displayed in employee's local currency.

Step 3: Build the Formula

Open Formula Assistant
Since we’re adding multiple values, we’ll use arithmetic operators
Formula structure:

In Workday, you build addition formulas by stacking operators:

Select Arithmetic function category → Add

Parameter configuration:

Value 1: Worker > Compensation > Base Salary
Value 2: Worker > Compensation > Target Bonus Amount

Now we need to add more values. Add another Add function as a nested function:

Nested formula structure:

Add(
  Base_Salary,
  Add(
    Target_Bonus_Amount,
    Add(
      Annual_Equity_Value,
      Add(
        Benefits_Employer_Cost,
        Retirement_Annual_Match
      )
    )
  )
)

Alternative cleaner approach: Use parentheses arithmetic

(Base_Salary + Target_Bonus_Amount + Annual_Equity_Value + Benefits_Employer_Cost + Retirement_Annual_Match)

Some Workday tenants allow this direct arithmetic notation in the Formula Assistant.

Step 4: Handle Null Values

Problem: If any component is null (employee has no equity, for example), the entire calculation returns blank.

Solution: Use Condition function to convert nulls to zero:

For each field, wrap it in a condition:

Condition(
  Field_Name IS NULL,
  0,
  Field_Name
)

Complete formula with null handling:

Add(
  Condition(Base_Salary IS NULL, 0, Base_Salary),
  Add(
    Condition(Target_Bonus IS NULL, 0, Target_Bonus),
    Add(
      Condition(Equity_Value IS NULL, 0, Equity_Value),
      Add(
        Condition(Benefits_Cost IS NULL, 0, Benefits_Cost),
        Condition(Retirement_Match IS NULL, 0, Retirement_Match)
      )
    )
  )
)

This ensures workers without equity or bonuses still get a total compensation value.

Step 5: Test the Calculated Field

Test with diverse compensation scenarios:

Test Case 1: Executive with full package

Base: $150,000
Bonus: $50,000
Equity: $75,000
Benefits: $15,000
Retirement: $12,000
Expected Total: $302,000

Test Case 2: Entry-level employee (no equity or bonus)

Base: $45,000
Bonus: $0 (null)
Equity: $0 (null)
Benefits: $8,000
Retirement: $2,250
Expected Total: $55,250

Test Case 3: Part-time (no benefits)

Base: $25,000
Bonus: $0 (null)
Equity: $0 (null)
Benefits: $0 (null)
Retirement: $0 (null)
Expected Total: $25,000

Step 6: Create Total Rewards Statement Report

Search: Create Custom Report
Report Name: Total Rewards Statement
Business Object: Worker
Add Columns:
- Worker Name
- Base Salary
- Target Bonus Amount
- Annual Equity Value
- Benefits Employer Cost
- Retirement Annual Match
- CF_Worker_Total_Compensation_Annual (prominently displayed)
Formatting:
- Format all currency fields with $ symbol
- Bold the Total Compensation column
- Add subtotals by organization
Security:
- Configure report to be visible only to worker themselves and their HR partner
- Use Worktags to limit data access appropriately

Step 7: Activate and Deploy

Test report with 20 diverse employees
Conduct UAT with HR team
Activate calculated field
Share report with managers for annual compensation conversations

Business Result: Employees see their $75K salary is actually a $92K total package, improving retention and reducing compensation complaints by 34%.

Scenario 2: Conditional Benefits Eligibility Flag

Business Need: Automatically determine benefits eligibility based on multiple criteria to eliminate manual review.

Eligibility Rules:

Employee must be Active employment status
AND must meet ONE of these:
- Age ≥ 26 OR
- Tenure ≥ 12 months OR
- Job Level = Executive
AND NOT on temporary employment status

Step 1: Create Supporting Calculated Fields First

Before creating the eligibility flag, create helper calculated fields:

Helper Field 1: Tenure in Months

Name: CF_Worker_Tenure_Months
Formula: Date_Difference(Hire_Date, Current_Date(), "Months")

Helper Field 2: Age in Years

Name: CF_Worker_Age_Years
Formula: Date_Difference(Birth_Date, Current_Date(), "Years")

Save and activate these first.

Step 2: Create the Eligibility Boolean Calculated Field

Search: Create Calculated Field
Field Name: CF_Worker_Benefits_Eligible_Flag
Business Object: Worker
Function: True/False Condition

Step 3: Build Complex Conditional Logic

In Formula Assistant, select: True_False_Condition

Build the logic in layers:

Layer 1: Check Employment Status is Active

Employment_Status = "Active"

Layer 2: Check Age OR Tenure OR Executive qualification

Use Condition functions with OR logic:

(CF_Worker_Age_Years >= 26)
OR
(CF_Worker_Tenure_Months >= 12)
OR
(Job_Level = "Executive")

Layer 3: Exclude Temporary Workers

NOT (Employee_Type = "Temporary")

Complete formula combining all layers:

True_False_Condition(
  (Employment_Status = "Active")
  AND
  (
    (CF_Worker_Age_Years >= 26)
    OR
    (CF_Worker_Tenure_Months >= 12)
    OR
    (Job_Level = "Executive")
  )
  AND
  NOT (Employee_Type = "Temporary")
)

How to build this in Formula Assistant:

Select True_False_Condition function
In the logical expression parameter, click Add Condition
Build first condition: Employment_Status = “Active”
Click AND operator button
Click Add Group to create nested OR conditions
Inside the group, add three conditions with OR between them
Outside the group, add another AND operator
Add final NOT condition for temporary status

The Formula Assistant displays this as a visual logic tree:

└── True_False_Condition
    └── AND
        ├── Employment_Status = "Active"
        ├── OR
        │   ├── CF_Worker_Age_Years >= 26
        │   ├── CF_Worker_Tenure_Months >= 12
        │   └── Job_Level = "Executive"
        └── NOT
            └── Employee_Type = "Temporary"

Step 4: Test with Edge Cases

Create test scenarios:

Should Return TRUE:

27-year-old new hire (meets age requirement)
24-year-old with 13 months tenure (meets tenure)
23-year-old VP hired yesterday (meets executive level)

Should Return FALSE:

25-year-old with 11 months tenure (doesn’t meet any criteria)
30-year-old temporary worker (excluded by NOT condition)
Terminated employee with 5 years tenure (fails active status)

Step 5: Integrate with Benefits Enrollment Business Process

Search: Edit Business Process
Open: Benefits Enrollment process
Find the Condition step that determines eligibility
Replace manual conditions with: CF_Worker_Benefits_Eligible_Flag = True
Save business process

Result: Benefits enrollment now automatically includes/excludes employees based on the calculated field logic. Manual review eliminated, saving 20 HR hours per month.

Advanced Tenant Configuration

Working with the Calculation Tab

The Calculation tab in the calculated field configuration screen provides advanced options:

Available Options:

Function – Select your calculation function
Return Blank When Function in Error – Error handling
Field Type Override – Force specific return type
Decimal Places – For numeric/currency fields
Use Grouping Separators – Add commas to large numbers

Display Options Configuration

The Display tab controls how the calculated field appears in reports:

Display Settings:

Display Name – What users see in field pickers (can differ from technical name)
Description – Tooltip text when users hover over field
Category – Organize related calculated fields together
Prompt-able – Allow use as report prompt

Best practice: Use descriptive display names for business users:

Technical Name: CF_Worker_Tenure_Months
Display Name: Employee Tenure (Months)

Managing Calculated Field Versions

When you need to update a production calculated field:

Safe Update Process:

Don’t edit the production field directly
In your sandbox tenant, create: CF_Worker_Tenure_Months_v2
Build and test the new logic
Create a test report comparing v1 and v2 results
Validate differences are expected
In production, edit the original calculated field
Update the formula to match v2
Save changes
Monitor reports for 48 hours

Why this approach?

Maintains history of the original formula
Allows side-by-side comparison
Reduces risk of breaking existing reports
Provides rollback option if issues arise

Performance Optimization in Your Tenant

Calculated fields can impact report performance.

Performance Testing Methodology

Create a test report with your calculated field
Run against full production data volume (e.g., all 10,000 employees)
Record execution time
If over 60 seconds, investigate optimization

Common Performance Issues

Issue 1: Complex Nested Conditions

Problem: 7+ levels of nested IF statements
Solution: Break into multiple simpler calculated fields

Issue 2: Expensive Aggregations

Problem: Counting or summing across thousands of related records
Solution: Use incremental aggregation or pre-calculate in nightly job

Issue 3: Multiple Related Object Lookups

Problem: Traversing 5+ object relationships
Solution: Flatten data structure or create intermediate calculated fields

Monitoring Performance in Production

Use the Maintain Calculated Fields report to monitor:

Sort by Reference Count (descending)
High-usage calculated fields deserve performance attention
Review execution time logs in Workday Analytics
Optimize fields used in >50 reports

Security and Governance

Security Domain Setup

To grant calculated field creation access:

Search: Maintain Security Groups
Open your administrator security group
Click: Assigned Domains tab
Click: Add
Search for: Custom Field Management domain
Add with appropriate permissions
Save security group

Audit and Compliance

Track calculated field changes:

Search: View Audit Trail
Filter by:
- Business Object: Calculated Field
- Date Range: Last 30 days
- Action Type: Create, Edit, Delete
Review who made changes and when
Export audit log for compliance documentation

Naming and Organization Standards

Implement organizational standards:

Standard Naming Convention:

CF_[BusinessObject]_[Description]_[DataType]

Examples:

CF_Worker_Tenure_Months_Numeric
CF_Position_Over_Budget_Boolean
CF_Organization_Total_Headcount_Numeric
CF_Worker_Full_Name_Formatted_Text

Category Organization:

Create calculated field categories in Workday:

Compensation Calculations
Tenure and Service
Performance Metrics
Eligibility Flags
Integration Data Prep

This makes calculated fields easier to find in the Maintain Calculated Fields report.

Troubleshooting Common Tenant Issues

Issue: Calculated Field Doesn’t Appear in Reports

Symptoms: After creating calculated field, it’s not visible in report column picker.

Diagnosis Steps:

Check if calculated field is Active
- Search: Maintain Calculated Fields
- Find your field
- Verify Active column shows ✓
Verify correct Business Object
- Report must be based on same business object as calculated field
Check Security
- Do you have access to underlying fields?
- View Security Groups to verify

Resolution:

If inactive: Activate the calculated field
If wrong business object: Recreate on correct object
If security issue: Add to appropriate security group

Issue: Calculated Field Returns Blank Unexpectedly

Symptoms: Calculated field shows blank when you expect a value.

Diagnosis Steps:

Check “Return Blank When Function in Error” setting
- Temporarily disable to see actual error
Test with specific worker who shows blank
Verify source fields have values for that worker
Check for null value handling in formula

Resolution:

Add null checks with Condition functions
Verify field pickers selected correct fields
Test formula logic with diverse data

Issue: Report Performance Degrades After Adding Calculated Field

Symptoms: Report that previously ran in 15 seconds now takes 3+ minutes.

Diagnosis Steps:

Run report without calculated field
Compare execution times
Review calculated field complexity
Check for aggregations or multiple lookups

Resolution:

Simplify formula
Break into multiple calculated fields
Use indexed fields as sources
Consider batch calculation alternative

Migration from Sandbox to Production

Pre-Migration Checklist

Before migrating calculated fields to production:

✓ Testing Complete:

☐ Unit testing with diverse workers passed
☐ Report testing validated accuracy
☐ UAT approval received from business users
☐ Performance testing shows acceptable runtime

✓ Documentation:

☐ Business description complete
☐ Usage documented (which reports, processes)
☐ Known limitations noted
☐ Test results documented

✓ Security:

☐ Derived security reviewed
☐ Access tested with different roles
☐ Sensitive data handling verified

✓ Deployment Plan:

☐ Change window scheduled
☐ Stakeholders notified
☐ Rollback plan prepared
☐ Post-deployment monitoring planned

Migration Process

Step 1: Document Sandbox Configuration

Open calculated field in sandbox
Take screenshots of all configuration tabs
Copy formula text
Document parameter values
Export PDF of configuration

Step 2: Create in Production Tenant

Login to production tenant
Search: Create Calculated Field
Recreate exact configuration from sandbox
Copy formula from documentation
Save (inactive)

Step 3: Production Testing

Test with 10-20 production workers
Compare results to sandbox expected values
Verify no errors
Check performance with production data volume

Step 4: Activate

Activate calculated field
Test immediately in a simple report
Monitor system performance for 30 minutes
Check for error logs

Step 5: Post-Deployment Communication

Email report writers that new field is available
Update internal documentation
Add to calculated field catalog
Schedule follow-up review in 2 weeks

Best Practices for Tenant Management

Quarterly Calculated Field Audit

Every 90 days, review all calculated fields:

Run Maintain Calculated Fields report
Sort by Reference Count
Identify unused fields (Reference Count = 0)
Review if still needed or can be deactivated
Update descriptions for clarity
Test critical high-usage fields

Calculated Field Library Documentation

Maintain an internal knowledge base:

Document for each calculated field:

Business purpose and use cases
Formula logic explanation
Example calculations
Known limitations
Reports and processes that use it
Owner and SME contacts
Change history

Training for Report Writers

Conduct quarterly training sessions:

Training Topics:

How to find calculated fields in column pickers
Understanding calculated field naming conventions
When to request new calculated fields
Testing calculated fields in reports
Troubleshooting blank values

Conclusion

Implementing calculated fields in your Workday tenant requires understanding not just formulas, but the complete configuration ecosystem. From security domain setup to Formula Assistant navigation, from testing protocols to production deployment, each step ensures reliable, performant calculated fields that solve real business problems.

Start with simple calculations like tenure to learn the tenant interface, then progressively build more complex conditional logic and multi-field calculations. Always test thoroughly in your sandbox environment, document comprehensively, and follow organizational governance standards.

The Maintain Calculated Fields report is your control center—bookmark it, review it regularly, and use it to audit your calculated field library quarterly. With proper tenant management practices, calculated fields become a strategic asset that eliminates manual work, ensures data consistency, and enables self-service analytics across your organization.

Now you’re ready to login to your Workday tenant and start building production-ready calculated fields that transform your HR operations.

October 23, 2025

Your Workday Accounting Backbone
Workday Accounting

If Workday is the brain of your finance system, the accounting backbone is its spine: Companies, Ledgers, Worktags and Posting Rules. When these four are designed well, every supplier invoice, customer invoice, expense report and journal flows cleanly into the General Ledger, and your reports match how the business actually thinks. When they are not, you get mispostings, reconciliation headaches and a long queue of “please fix my coding” tickets.

This guide walks through how to think about and explain that backbone in Workday language, but in a way that finance and accounting teams immediately recognize.

Companies: the legal and reporting anchors

In Workday Financials, Companies (sometimes called Company / Entity) represent the legal or accounting units where you keep books and produce financial statements.

From a finance perspective, a Company is:
- A legal entity that needs its own statutory accounts.
- The core object Workday uses for balance sheets, P&Ls and trial balances.
- The anchor for settings like functional currency, year-end close rules and consolidation.
Key design decisions:
- Define one Company per legal entity that reports separately (for example, “US Corp”, “India Pvt Ltd”, “UK Ltd”).
- Use Company Hierarchies to group companies for management reporting and consolidation (e.g., “EMEA Region”, “Global Consolidation”).
- Make sure every operational process (Procurement, Expenses, Customer Invoicing, Projects) is configured to capture the right Company on each transaction.
Once Companies are set correctly, finance users can filter reports by entity and trust that every transaction belongs to the right legal book.

Ledgers: where the accounting happens

If Companies answer “who,” Ledgers answer “which book.” In Workday, ledgers hold accounting entries for a Company.

Typical patterns:
- A Primary Ledger per Company, which holds your main accounting entries.
- Optional additional ledgers for adjustments, local GAAP vs. group GAAP, or management-only entries.
In daily work you see ledgers in:
- Journals – you pick the ledger (often implicit via Company) and accounting date/period.
- Financial reports – you can specify which ledger(s) to include for a given statement.
For most non-technical users:
- You do not configure ledgers yourself, but knowing which ledger a report uses (Primary vs. Adjustment) explains why numbers may differ from other tools.
- You can be confident that all subledger activity (AP, AR, Expenses, Projects, Payroll) ultimately posts into the ledger defined for that Company.
Think of the ledger as the “book” your external auditors care about; everything else is just detail feeding into it.

Worktags: replacing account strings with smart labels

The real Workday magic for accounting is Worktags. Instead of long account strings (Company–Department–Account–Project…), Workday uses Worktags as flexible labels on each line.

Worktags:
- Classify transactions for financial, operational and external reporting.
- Can be assigned to any line that generates a financial update: requisitions, invoices, expenses, time, journals, payroll, etc.
Common Worktags in many tenants include:
- Cost Center – the department or unit owning the cost.
- Fund / Program / Grant / Project / Gift – funding or project dimensions, often called Driver Worktags.
- Spend Category – what you are buying (e.g., Office Supplies, Travel – Airfare), analogous to an expense account.
- Revenue Category – what income you’re recognizing (e.g., Product Revenue, Service Fees).
- Location, Assignee, Custom Worktags – extra slices for where and who.
Important concepts:
- Driver Worktags: the main Worktags users pick (for example, Project or Cost Center). These trigger Related Worktags to auto-populate, making entry easier and more consistent.
- Related Worktags: automatically filled-in tags tied to the Driver (for example, choose Project → default Cost Center and Program appear).
For the AP team, expense users or journal preparers, this means:
- You focus on choosing the right Worktags instead of trying to remember a long string of codes.
- Changing one Worktag (e.g., Project) can automatically adjust related tags, keeping combinations valid and reportable.
Posting Rules: the engine translating worktags into accounts

Behind the scenes, Workday’s Account Posting Rules (often described as the “accounting rules engine”) take those Worktags and decide which Ledger Accounts to use.

Key idea:
- Users pick Worktags like Company, Cost Center, Spend Category, Project.
- Posting Rules map those combinations to ledger accounts and build the debit/credit lines for the journal.
Examples:
- Entity: US Corp + Spend Category: “Office Supplies” → Debit 640000 (Office Supplies Expense), Credit 200000 (AP).
- Entity: India Pvt Ltd + Spend Category: “Travel – Airfare” → Debit 642100 (Travel Expense), Credit 200000 (AP).
Benefits:
- End users no longer select ledger accounts directly; they select the business-friendly Worktags, and the system applies consistent accounting.
- Finance can centrally manage accounting logic without retraining every user when accounts or rules change.
From a design perspective:
- Account Posting Rule Sets should mirror your chart of accounts and key Worktag dimensions.
- Changes to accounting (for example, moving certain spend to a new account) are made in rules, not transaction screens.
How it all comes together in a transaction

Let’s walk a basic supplier invoice through the backbone:
1. Company / Entity
  - AP selects Company “US Corp” on the supplier invoice. This determines which books and ledger are used.
2. Worktags on the invoice line
  - Cost Center: “Sales – East”
  - Spend Category: “Travel – Airfare”
  - Project: “Project X” (as a Driver Worktag, auto-filling Cost Center and maybe Program)
3. Posting Rules
  - Workday’s Account Posting Rule Set sees Company + Spend Category (and possibly Project/Fund) and maps to the correct expense and AP accounts.
4. Ledger
  - The system posts the resulting journal to the Primary Ledger for US Corp in the appropriate period.
The AP user only needed to know: the correct Company and Worktags. The complex accounting logic happened automatically and consistently.

Design tips for a strong accounting backbone

When setting up or improving your backbone, a few principles help:
- Start with your Foundation Data Model (FDM)
  - Align Companies, Cost Centers, Programs, Projects and other Worktags to how the business actually manages and reports.
  - Treat FDM design workshops like building the foundation of a house: get them right before everything else.
- Keep Worktag usage clear and controlled
  - Decide which Worktags are required on which business events (for example, Cost Center and Spend Category always required on journals).
  - Document which Worktag combinations are valid; misuse of Worktags is a major cause of messy reporting.
- Centralize Posting Rules ownership
  - Assign accounting or finance system owners to manage Account Posting Rule Sets.
  - Test new rules with sample transactions before moving them to production to avoid mispostings at scale.
- Train users on Worktags, not on GL codes
  - Provide quick reference guides showing which Worktags to use for common scenarios instead of giving them the chart of accounts.
  - Show how Worktags appear in reports so users understand why accurate tagging matters.
When the backbone is clear and users know their part, finance can shift from fixing coding errors to analyzing the business.

A well-designed accounting backbone in Workday – with clean Companies, structured Ledgers, thoughtful Worktags and robust Posting Rules – turns Workday into a reliable single source of truth for finance. Transactions flow from operations to the GL with minimal manual intervention, and your reports finally reflect the real story of the business without endless offline rework.
July 28, 2025
Fixed Assets in Workday, Made Practical
Fixed assets can quietly become one of the messiest areas in any ERP. In Workday, you manage assets end to end—from acquisition through capitalization, depreciation and disposal—inside a single Financials platform. When the design is tight, you get accurate asset values, clean depreciation and clear audit trails. When it is not, you end up with misclassified spend, CIP that never closes and painful manual fixes.

This guide walks through a practical, Workday‑practitioner view of how to handle the full fixed asset lifecycle.

1. Start with policy: what counts as a capital asset?

Before configuring Workday, align on capitalization policy:
- Minimum capitalization thresholds by asset type.
- Useful life ranges for major categories (IT, furniture, buildings, leasehold improvements).
- Treatment for internal projects vs direct purchases.
Why it matters in Workday:
- Capitalization rules decide which Spend Categories and Projects should feed Business Assets instead of pure expenses.
- Useful life and books drive depreciation schedules and journal postings.
Capture these decisions in a policy document and use them to drive your Spend Category, Project and Asset configuration.

2. Acquisition paths: how assets enter Workday

In Workday Financials, assets usually originate in one of three ways:
- Direct purchase
  - Capital‑eligible invoices (from Procurement/AP) coded with capital Spend Categories (for example, “Capital Equipment”).
  - These can create Business Assets directly or via asset addition processes.
- Capital projects
  - Costs for construction or implementation tracked on Capital Projects (labor, materials, services).
  - At completion, aggregated into Project Assets, then converted to Business Assets.
- Manual additions / conversions
  - Legacy assets from prior systems or one-off additions created directly in the Business Asset module.
Best practices:
- Use dedicated Spend Categories and Worktags for capitalizable spend so you can easily identify what should become assets.
- For larger initiatives, prefer Capital Projects so all related costs flow into CIP and can be capitalized systematically.
This keeps acquisition data structured and traceable.

3. Capitalization: turning costs into business assets

Capitalization is the process of turning eligible costs (invoices, project costs) into Business Assets that will be depreciated. Workday supports both project‑driven and direct capitalization.

Project-based capitalization:
- Use Project Assets in capital projects to group related costs (for example, building, IT infrastructure).
- Run Project Capitalization to convert Project Assets into Business Assets when ready, moving balances from Construction in Progress (CIP) to asset accounts.
Direct capitalization:
- For standalone purchases, use asset addition processes (manual or semi‑automated from AP) to create Business Assets directly from invoices.
Key configuration:
- Define Asset Books (for example, External Reporting/GAAP, Tax) with their own depreciation settings.
- Set up Asset Categories and Accounting Rules mapping Spend Categories and asset types to the right GL accounts (CIP, Asset, Accumulated Depreciation, Gain/Loss).
Control points:
- Require appropriate approvals for capitalization, especially for large or unusual items.
- Ensure audit trail from original invoice or project to the Business Asset record.
When done correctly, you can trace every capitalized amount back to its source transactions.

4. Depreciation: automating the monthly grind

Once assets are created and placed In Service, Workday’s Asset Depreciation engine calculates periodic depreciation and posts journals to the GL.

Core elements:
- Depreciation Method – straight line, declining balance, or other supported methods depending on jurisdiction.
- Useful Life – defined in years or periods for each Asset Category or individual asset.
- Depreciation Convention – for example, mid‑month or mid‑year conventions, where applicable.
In practice:
- Use Record Asset Depreciation (often scheduled) to post depreciation by period for each Asset Book.
- Review depreciation reports by Book, Company and Asset Category to validate totals and unusual items.
Best practices:
- Standardize depreciation methods and useful lives per asset class; override only when justified.
- Align planning tools (for example, Workday Adaptive Planning) with actual depreciation outputs where CapEx forecasts are critical.
- Ensure depreciation runs are part of your regular period close checklist.
Workday keeps detailed life‑to‑date depreciation history, so adjustments and audits remain manageable.

5. Transfers, adjustments and corrections

Real life brings relocations, reclassifications and mistakes. Workday supports asset transfers and cost adjustments without losing history.

Examples:
- Transfers
  - Move assets between Cost Centers, Locations or Companies while keeping the same asset ID and history.
  - Repost future depreciation to new Worktags, adjusting GL impacts appropriately.
- Cost adjustments
  - Increase or decrease acquisition cost (for example, additional capitalizable improvements, corrections).
  - Workday recalculates depreciation from the effective date forward; for reductions, depreciation can be unwound prospectively.
Governance tips:
- Limit who can perform asset transfers and cost adjustments; require documentation for significant changes.
- Use reports to identify assets with unusual adjustments or frequent changes.
Handling these properly keeps your books accurate even as operational realities shift.

6. Disposal: closing the loop on asset life

Eventually, assets are sold, scrapped, retired or transferred out. Workday supports asset disposal workflows that remove assets from the books and recognize gains or losses.

Disposal steps:
- Initiate Dispose Asset with details of disposal date, method (sale, scrap, transfer) and, for sales, proceeds.
- Workday calculates:
  - Remaining net book value.
  - Gain or loss on disposal (proceeds minus net book value).
  - GL entries to remove Asset and Accumulated Depreciation balances.
Best practices:
- Coordinate with physical asset tracking (tags, IT asset tools) so disposals in Workday match reality.
- Require approvals for high‑value disposals to satisfy internal controls and audit.
- For inter‑entity transfers, use appropriate processes (transfer vs disposal) to avoid accidental gain/loss on internal moves.
Closing the loop correctly ensures the fixed asset register matches both the physical world and your financial statements.

7. Reporting and controls: make your asset data usable

When the lifecycle is configured well, Workday provides strong reporting out of the box:
- Asset Registers – by Company, Asset Category, Location, Cost Center.
- Depreciation Reports – current period and life‑to‑date by Asset, Category, and Book.
- CIP and Project Capitalization reports – tracking costs pending capitalization and recently capitalized assets.
Control routines:
- Reconcile asset subledger totals to GL accounts for Assets, CIP, Accumulated Depreciation and Gains/Losses each period.
- Review assets with zero net book value still in service, or assets fully depreciated but still important operationally.
- Monitor additions and disposals by period to detect unusual patterns.
With this discipline, fixed assets become a strength—not a perennial audit finding.

Managing fixed assets in Workday is ultimately about treating the asset lifecycle as a first‑class process: clear policies, structured acquisition, disciplined capitalization, automated depreciation and controlled disposal. When each step is designed and owned, your asset balances, depreciation and gains/losses will stand up to scrutiny and support better investment decisions.
July 8, 2025
Tax and Compliance in Workday Financials
Tax and compliance in Workday Financials is not just a “settings” exercise. It is about using Workday’s tax framework, period close tools and audit capabilities so transactions are taxed correctly, books close on time and auditors can follow the trail without spreadsheets. Workday’s global tax framework, accounting rules and internal control features are built for exactly this, but only pay off when design is intentional.

This guide covers three pillars: Tax Rules, Period Close, and Audit‑Ready Reporting for Workday Financials.

1. Design a tax framework before touching configuration

Start with your tax footprint:
- In which countries do you operate, and which taxes apply (VAT, GST, sales tax, withholding, local levies)?
- Which transactions need tax (supplier invoices, customer invoices, expenses, P‑Card, journals)?
- Which roles own tax configuration and sign-off (indirect tax, corporate tax, local controllers)?
Workday’s tax framework lets you:
- Configure Tax Authorities, Tax Rates and Tax Categories per jurisdiction.
- Embed tax logic into Posting Rules and transaction‑level determination so tax is calculated automatically based on rules, not manual selection.
Good practice is to mirror your tax policy and compliance needs in Workday as configurations, not workarounds.

2. Configure tax rules for real transactions, not edge cases

In Workday, tax logic is driven by a combination of:
- Tax Authority and Regime – the jurisdiction and overarching rules.
- Tax Rates – standard, reduced, zero, exempt, etc., effective-dated.
- Tax Categories – how items are treated for tax (for example, Goods – Standard, Services – Reduced).
Key design decisions:
- For AP and Procurement: decide how tax is determined from Supplier, Ship‑To location, Spend Category and Company. Indirect tax rules can be embedded in posting rules so the right tax code applies automatically.
- For AR and Billing: configure tax rules based on Customer, Sold‑To/Ship‑To, Product/Revenue Category and contract terms.
- For Expenses: define which Expense Items are taxable and whether tax is recoverable or not, country by country.
Patterns that work:
- Use rule‑based tax determination so end‑users rarely pick tax codes manually.
- Keep tax rate tables clean and effective‑dated; avoid leaving old rates active.
- Centralize maintenance of tax rules under tax specialists, not general finance users.
This reduces mis‑taxed transactions and manual corrections, especially for cross‑border or multi‑rate environments.

3. Period close: build discipline into Workday, not outside it

Workday includes tools to support a structured period close: calendar management, validations, reconciliations and workflow.

Core close elements:
- Ledgers and Periods – define fiscal calendars and periods at Company and Ledger level, with clear open/close states.
- Close checklists – many organizations use Workday reports combined with internal checklists (for example, unreconciled accounts, unposted journals, orphaned CIP, tax accruals).
- Validations and Posting Rules – enforce that only valid Worktag and tax combinations post, reducing cleanup at month‑end.
Best practices from efficient closes:
- Use Workday’s period close orchestration (tasks, assignments and reminders) to track which teams have completed their steps—AP, AR, Projects, Assets, Tax.
- Lock periods progressively: close subledger activity (AP/AR/Projects) before final GL journal posting.
- Embed tax accruals and tax control checks into the close (for example, VAT/GST payable vs returns, deferred tax where applicable).
When close routines live in Workday instead of spreadsheets, it becomes easier to shorten close cycles and demonstrate control to auditors.

4. Make audit and compliance part of the design, not an afterthought

Workday provides built‑in capabilities for internal controls, audit trails and compliance reporting.

Key features to leverage:
- Audit Logs and History
  - Workday retains change history for configurations, master data and many transactions (who changed what, when).
  - Use these logs and standard reports during audits to show the lifecycle of key changes (for example, tax rates, posting rules).
- Segregation of Duties (SoD) and Access Reviews
  - Combine security model design (domain and role‑based security) with periodic reviews to show that no one person can both configure tax and process high‑risk transactions end‑to‑end.
- Compliance and Certifications
  - Workday itself undergoes third-party security and compliance assessments (for example, SOC, ISO), which you can reference in your control framework.
Practical steps:
- Maintain a Risk and Controls Matrix that maps Workday processes (including tax setup and period close) to specific controls and report evidence.
- Use targeted reports rather than raw data dumps for auditors—for example, “Tax rate change log”, “Journal entries posted after close”, “User access to tax configuration domains”.
This reduces audit time and avoids last‑minute scrambles for evidence.

5. Build audit-ready tax and financial reporting

Finally, design reports that answer the questions tax authorities, regulators and auditors will actually ask. Workday’s reporting and analytics engine can support this if wired correctly.

Examples:
- Indirect tax (VAT/GST/Sales tax) reports
  - Summaries of taxable base, tax collected, tax paid and net payable by jurisdiction.
  - Drill‑through from summary to transaction level, showing Customer/Supplier, invoice, tax rate and Worktags.
- Statutory reporting
  - Local GAAP/IFRS P&L and Balance Sheet by Company using the relevant Ledger and Worktags.
  - Tax‑sensitive accounts clearly split (for example, VAT payable vs receivable, income tax expense vs deferred tax).
- Internal compliance and exception reports
  - Transactions missing tax where it should apply, or with unusual tax codes.
  - Journals posted directly to tax accounts (bypassing standard flows) for investigation.
  - Close-status dashboards showing outstanding reconciliations or unapproved journals.
Design these reports once, then reuse them every period and every audit.

When you treat Tax Rules, Period Close and Audit‑Ready Reporting as an integrated design problem in Workday Financials, compliance stops being a manual overlay and becomes part of how the system runs. Tax is determined and posted by rules, closes follow a repeatable pattern, and auditors can see end‑to‑end evidence inside Workday rather than scattered across spreadsheets and emails.
April 3, 2025

Category: Workday for Finance

Connecting Workday Financials, End to End

Foundation: Workday Integration Cloud and FDM

GL integration patterns: feeding analytics and other ERPs

Proven GL patterns:

Key practices:

Banking integration patterns: payments and bank connectivity

Outbound to banks:

Inbound from banks:

Best practices:

Payroll integration patterns: global payroll via Cloud Connect

Core patterns:

Why Cloud Connect matters:

Architectural tips: pattern choices, not one-offs

Protecting the Books in Workday

Understand the Workday security model for finance

Build segregation of duties into the model

Approval controls: business processes that actually protect value

Use tools and automation for SoD and control monitoring

Make security and controls usable for finance

Banking and Cash in Workday, Without Chaos

Step 1: Treat bank accounts as master data, not “just details”

Step 2: Understand how settlements tie subledgers to cash

Step 3: Bank reconciliation without the spreadsheet circus

Step 4: Cash positioning that treasury actually trusts

Step 5: Governance to keep banking and cash from drifting

Contract-to-Cash in Workday, Done Right

Step 1: Understand the core contract-to-cash objects

Step 2: Design Customer Contracts that reflect real products and services

Step 3: Build billing schedules that match cash realities

Step 4: Separate billing from revenue with robust recognition schedules

Step 5: Automate allocation and multi-element arrangements

Step 6: Integrate contract-to-cash with projects and AR

Step 7: Governance, modifications and renewals

Workday Financials for Non-Tech Finance

Entities: who’s doing the accounting?

Ledgers: where transactions land

Worktags: Workday’s replacement for long account strings

How entities, ledgers and worktags meet in a transaction

Worktags in reports: how finance actually uses them

Tips for non-technical finance users to get comfortable fast

Project Accounting in Workday, Step by Step

Project Accounting

Step 1: Design your project Worktag model

Step 2: Create projects with the right attributes

Step 3: Capture time and expenses against projects

Step 4: Capture procurement and AP costs to projects

Step 5: Budgeting and tracking against plan

Step 6: Billing and revenue for customer projects

Step 7: Governance and “project hygiene”

Workday Calculated Fields: Complete Tenant Implementation Guide

Understanding Your Workday Tenant Environment

Tenant Types and Configuration Environment

Implementation Tenant (Sandbox)

Production Tenant

Preview Tenant (if applicable)

Security Domains: The Foundation of Calculated Field Access

Custom Field Management Domain

Private Calculated Fields Management Subdomain

Derived Security: How Calculated Fields Inherit Permissions

Step-by-Step: Creating a Calculated Field in Your Tenant

Real-World Example: Employee Tenure in Months

Phase 1: Accessing the Create Calculated Field Task

Method 1: Global Search (Most Common)

Method 2: Task Navigation (Legacy Method)

Method 3: From Maintain Calculated Fields Report

Phase 2: The Create Calculated Field Configuration Screen

Phase 3: Configuring the Field Name and Business Object

Field Name Configuration

Business Object Selection

Add Business Description

Phase 4: Using the Formula Assistant

Opening the Formula Assistant

Selecting Your Function

Configuring Function Parameters

Parameter 1: Start Date

Parameter 2: End Date

Parameter 3: Return Type

Formula Syntax Visualization in the Assistant

Adding Error Handling