A fixed-fee implementation signs at $480,000 across four deliverables. Ten months later the work is done, the client is happy, and $120,000 is still sitting unbilled because nobody told finance that phase three closed back in March.

That is the failure milestone billing in Workday exists to prevent. It is also the failure a badly configured milestone schedule quietly creates. The difference comes down to one thing: whether the milestone is an event the system is watching, or a note in somebody's calendar.

The milestone field lives on the billing schedule header, and a header can carry only one milestone. So the four-deliverable, $480,000 deal from the top can't be one schedule with four milestone installments sitting on it — it has to be four contract lines, each a Fixed Amount line type with its own milestone-type billing schedule, each releasing independently when its milestone completes. The fixed fee project needs to be modelled in a way that aligns with the fee schedule and provides sufficient flexibility for when things change.

That distinction is worth holding onto, because it tells you when milestone billing is the wrong answer: the contract line amount has to be known and fixed at signature. Milestones control timing, not amount. If the value itself is variable, you want a transaction or usage line.

Milestones come in two forms: a customer milestone and a project milestone. The customer milestone is an independent object with a date, a name, and a description. The project milestone is a child of a project task, and inherits the task's name and date. Both can be linked to the billing schedule header, and how they release is different.

Manual completion is the release path for a customer milestone. A dedicated task enables the maintenance and modification of these types of milestones. Security to that task is usually limited to a customer manager and/or the finance team. When the milestone is complete, it gets manually marked as done, and the next billing run picks it up.

If the work lives in a Workday project, the milestone completion is more automated. When the project manager marks that task complete, the linked installment becomes eligible and the next billing run picks it up. No re-keying, and no gap between delivery declaring the work done and finance being able to invoice.

The mistake is treating manual as the default because it feels safer. If the trigger genuinely is a project task, wire it to the project task and take the human out of the transcription step. Reserve manual completion for events that live outside the project plan, and route it through a business process so completion is approved rather than asserted.

Automation here is worth arguing in control terms, not efficiency terms.

Every milestone completion is an event: timestamped, attributed to a named worker, carrying its own business process history. When the invoice lands, you can drill from the invoice line to the installment to the milestone to the project task that closed it and the approval that let it through. Attach the signed acceptance certificate to the milestone and the evidence travels with the transaction instead of living in a mailbox.

Cash and revenue cannot release until a defined event completes, and the record of who released it is created by the system at the time, not reconstructed for the auditor nine months later.

Before you build the schedule, answer one question: who, by name, marks each of these milestones complete, and what evidence do they hold when they do. Everything else in the configuration follows from that.

Working through a fixed-fee billing setup that keeps slipping? 

How milestone billing in Workday is built.

Milestone Billing in Workday: Configuration That Actually Delivers

A consultant books eight hours on a Friday afternoon. Nine weeks later the client questions that line on an invoice, and three people go looking for what happened in between.

What happened in between is the PSA billing workflow. Most of the pain in professional services billing comes from teams treating it as a handful of separate steps owned by separate functions, when it really is an inter-connected process chain. To illustrate how Workday PSA handles this chain, this post walks through an example for a consulting firm on time and materials. It is the foundational and most common shape and the one where the connections are easiest to see. Fixed fee, milestone, and retainer billing each have their own quirks and get their own posts later in this series.

The chain: project, time, expense, contract, invoice, revenue

Everything anchors on the project. The project carries the plan, phases and tasks, the resource assignments, and the billable flags. It also has to be tied to a customer contract line, because that link is what makes any transaction against it billable at all.

Time comes in against the project and/or task. When a consultant submits, Workday checks the worker's assignment, whether the task is billable, and whether the date falls inside the contract period. Approved time becomes a billable transaction carrying the worker, the role, the task, the hours, the bill rate, and the cost rate.

Expenses arrive at the same place from a different door. An expense report line coded to the project and marked billable produces a billable transaction too. The markup, the cap, and the treatment of non-billable items are not decided on the expense report. They are decided by the billing rules on the contract or through manual intervention.

The customer contract line is where the commercial agreement becomes configuration: the rate sheet, the rate hierarchy across worker, role, and task, what is billable, what is capped, and what carries markup.

The transaction billing schedule then sweeps eligible billable transactions on its cycle and produces the customer invoice. Revenue recognition runs off the same contract line. On a straightforward T&M engagement, revenue recognizes as the work is delivered and billed, which is why a rate problem shows up in revenue and margin at the same time it shows up on the invoice.

Six links, one system, one record. That is worth being specific about, because "integrated" gets used loosely.

You can drill from an invoice line back to the time block, the worker, and the day it was entered, without leaving Workday and without a support ticket. Cost rate and bill rate sit on the same transaction, so project margin is a live number rather than a month-end exercise. The billing and revenue status sits on the billable transaction, so reporting can be done in both directions.

There is no interface between the time system and the billing system to reconcile, no nightly file, and no drift between what delivery thinks was billed and what finance actually billed.

Firms running a standalone PSA tool alongside Workday Financials spend real effort keeping projects, workers, rates, and invoices in agreement across the boundary. That work disappears when the boundary does.

The failures are almost always at the joints, not inside any one step.

Use ad-hoc billable transactions to expand beyond

Not everything that belongs on a T&M invoice starts life as time or expense record in Workday. A subcontractor pass-through, a tooling or license charge, a negotiated credit, a fixed onboarding fee on an otherwise hourly engagement. The instinct is to fake a time entry or hand-edit the invoice. Both leave you with an audit trail that does not survive contact with a reviewer.

Create an ad-hoc billable transaction against the project and contract line instead. This way you can import transactions from other systems as well. It picks up the same billing rules, flows through the same billing schedule, carries the same revenue treatment, and stays visible in the same drill path as everything else. It is the pressure valve that lets a tightly configured T&M contract absorb the one-off without anyone going around the system.

Two guardrails. Give ad-hoc transactions their own revenue category so they do not distort utilization and effective rate reporting, and put a real approval step on them. Flexibility without a control is just an open door.

Start at the contract line and walk forward when you are debugging any of this. Nine times out of ten, an invoice that looks wrong is a contract that was configured for a deal nobody has sold in two years.

Working through a T&M billing setup that fights you? Contact us

A practitioner's walk through the Workday PSA billing workflow for time and materials consulting: how project, time, expense, billing, and revenue connect.

From Time Entry to Invoice: The PSA Billing Workflow Explained

The Billing Schedules You Need to Master in Workday

Every Workday Billing deployment eventually comes down to one key task: the Create Billing Schedule for Customer Contract task. It looks like a routine task. How you use it decides whether invoices track the contract cleanly for the next three years, or turn into a manual fix every single month.

While Customer invoices can be created as a standalone task, most companies use the option to generate them from a customer contract via billing schedule for recurring events. By using billing schedule templates the number of steps involved in the creation process is reduced and consistency is increased.

Most of the confusion isn't about the task itself. It's not knowing which billing method actually fits the deal in front of you, and confusing the billing schedule controls with revenue recognition. Get those two things straight and the system will be in sync with your business.

Note: While similar functionality exists for Sponsors/Grants as well, this post focuses exclusively on Customer Contracts.

A billing schedule and a revenue schedule do different jobs

Workday keeps them as separate objects on purpose, so a business can bill on one timeline and recognize revenue on another without one process distorting the other.

The classic case: an annual subscription contract. You bill the full amount on day one through the billing schedule. A separate revenue schedule spreads that same revenue evenly across the twelve months of service. Same contract line, two different clocks.

The billing schedules, and where each one earns its place

While the schedule type is optional in the task, it is a helpful way to flag its usage for reporting purposes or audit/business process controls. The 

 task lets you configure the billing schedule types for your tenant. You can inactivate ones you don't want your users to see or supply your unique description.

Consolidated or not: decide it when you build the schedule, not after

A billing schedule can group contract lines that span multiple contracts, or projects for the same company and customer, into a single schedule. That grouping decision, made when you build the schedule, determines whether one invoice is created across multiple contracts (i.e. consolidated) or not. Later, when you run Create Customer Invoices from Contracts, you choose a consolidation level for that run: by customer, by customer and billing schedule, or by customer and contract.

A consolidates billing schedule does not have all the same features as individual billing schedules. Hence it is important to make the decision carefully. Group too broadly and one correction on a single line forces a credit and rebill across the whole schedule.

Billing input and methods orchestrate the schedule

Another key factor is the input: is  it installment, transaction or prepaid based (also known as billing type). If the input is installment based then the billing schedule will create amounts to be billed on a set schedule. If the input is transaction based then the billing schedule will create invoices based on the actual transactions that have been logged against the contract line. A unique case is the prepaid option becuase it not only schedules the installments based a schedule for the full amount or a defined block but also triggers the  accounting for a prepaid balance.

If the schedule's billing type is installment, you can determine the installment creation via the 

The following billing methods are available:

The header of the billing schedule isn't administrative overhead. It's where Workday derives every date and process rule to be applied. Each billing schedule can for example have different PO numbers or generate different invoice type, which then can determine a different print form to be used. Leave it empty to default to the contract billing data.

Auto-Submit Invoices for Approval allows you to bypass business process approval steps for invoice generation since the scheduled installment have already been approved.

Automatically Submit Schedule via Contract Amendment only matters once Automatically Regenerate Installments is on. Skip it and every contract amendment leaves you with regenerated installments sitting unsubmitted, waiting for someone to notice and push them through approval by hand.

Templates carry the header so you don't rebuild it

A billing schedule template saves the header configuration (billing method, frequency, invoice date option, statutory invoice type, delivery overrides) once, so a new contract inherits it instead of forcing someone to re-enter Spread Even, monthly, 15th-of-month invoicing on every deal. For a firm signing contracts across several people and teams, that consistency is the difference between a clean schedule and one that needs review after every go-live.

With all these billing schedule options, it become important to know which one your contract actually calls so that invoices are processes accurately, timely and consistently. That decision, made during setup and in your day-to-day operation, is what determines whether your invoices match the deal for the life of the contract or fight it every cycle.

Reviewing your own billing schedule setup? 

Workday billing schedules control how and when you invoice, not how you recognize revenue. Here are the schedule options to know and where each one fits.

Looking for ways to make the Workday system your own? There are a few options to consider.

When Workday was a early pioneer in the Cloud ERP market, their differentiation was built on "one-code line" in stark contrast to legacy providers. Many SAP and PeopleSoft customers dreaded the costly upgrade projects that introduced risk and cost and provided very few tangible benefits. A "self-upgrading system" was to tale of dreams.
In order to facility this single-code line approach, customizations were non-existent. Instead a configurable standard software approach allow customer to make fast decision and adjust the features to their needs.

Many companies find that they need to augment standard software to improve user experience and feature functionality. Either the delivered features are incomplete or too complicated.
Adding custom fields to an existing Workday object may be a solution for some, but it comes with limitations (such as UI, busines process, etc.)

The quickest way to get new processes supported is by creating your own applications and integration them via applications. This could be done on any web application platform (such as Heroku or Next Js). This may be attractive for organziations that already have a development staff in house.

Workday has built out substantial capabilities over the past years that make it possible for customer and implementers to build Workday experience directly within the tenant.

Many vendors are now offering their applications on the Workday marketplace. Those are pre-packaged solutions that have been fully developed and tested.

As the Workday marketplace grows and matures, expect a lot more offerings from small to large solutions. Vendors such as ourselves are constantly looking to provide Workday customers with the tools they need.

How can your organization take advantage of the growing capabilities of the Workday Platform

Technology

Milestone Billing in Workday: Configuration That Actually Delivers

From Time Entry to Invoice: The PSA Billing Workflow Explained

The Billing Schedules You Need to Master in Workday

Workday Platform options