In large enterprises, the problem is rarely a shortage of good ideas; it is a surplus of uncoordinated ones. Every department has a "critical" initiative, every executive has a passion project, and every team is convinced their request deserves immediate allocation of resources.

Without a clear gatekeeper, organizations suffer from "intake chaos" where loudest-voice-wins prioritization rules, resources are chronically overcommitted, and strategic alignment is thrown out the window.

The traditional corporate cure for this chaos has historically been heavy governance: exhaustive business cases, multi-stage approval committees, and endless spreadsheets. But in today’s world, this governance is often built on a fragile web of external form tools, disconnected intake apps, and manual data re-entry. This tech fragmentation slows things down too much, paralyzing innovation, introducing security gaps, and dragging out time-to-market.

The modern solution? A structured, lightweight project intake process.

The Philosophy of "Structured yet Lightweight"

A structured and lightweight intake process balances control with speed. It establishes clear, predictable guardrails for how ideas are submitted, evaluated, and prioritized, but strips away the bureaucratic friction that slows down decision-making.

Instead of demanding a 10-page business case for an experimental feature, a lightweight process uses a tiered approach. It relies on context-aware forms that ask for just enough information at each stage to make an informed 'go/no-go' decision, automatically pulling in existing organizational details rather than asking the user to manually type them out again and again.

Core Benefits of the Lightweight Approach

By replacing complex templates with standardized, brief submission forms (often requiring fewer than 10 strategic questions), enterprises can evaluate proposals in days rather than months. This agility allows organizations to seize market opportunities before competitors do.

2. Native Security, Governance and Visibility

When project intake lives within the boundaries of your enterprise systems, sensitive project data, budgets, and resource plans remain secure. A structured approach ensures that security compliance isn't an afterthought or a custom-built integration API and it is inherited directly from your core organizational security policies. By keeping the information in generally available system allows to give both the requester and the approvers the visibility they need about where the request stands.

3. Resource Optimization and Reduced Burnout

When you control the top of the funnel, you protect the delivery teams at the bottom. A structured intake process acts as a dam, preventing teams from being flooded with half-baked requests and ensuring that resources are only committed to fully vetted, high-value initiatives.

How does this look in practice? Let’s examine two common enterprise scenarios.

Use Case 1: The IT Department’s Tiered Routing System

The Challenge: A global retail enterprise’s IT department was buried under a mountain of diverse requests, ranging from simple software integrations to multi-million dollar cloud migrations. Because requests were captured in an external form tool and manually transferred into their core project execution system, minor requests stalled, errors were frequent, and major strategic projects lacked visibility.

The Lightweight Solution: IT implemented a tiered, automated intake flow that leveraged pre-populated user profiles and smart routing.

The Result: Cycle times for minor requests dropped by 70%, administrative overhead plummeted due to zero data re-entry, and executive leadership could focus their energy entirely on high-impact strategic initiatives.

Use Case 2: Marketing’s Alignment-First Intake

The Challenge: A financial services firm's marketing department was constantly thrashing because regional heads could bypass standard channels to demand custom campaigns, leading to fragmented brand messaging and burned-out designers.

The Lightweight Solution: The firm established a centralized intake portal tied to a single strategic question: "Which of our three annual corporate goals does this campaign directly support?" If a submitter could not map their request to a core goal with supporting data, the system automatically redirected them to self-service templates. To keep inputs high-quality and consistent, the portal used inline AI assistance to help requesters clearly draft and refine their business justifications on the spot.

The Result: The marketing department reduced rogue project requests by 45%, freeing up creative resources to deliver highly polished, unified campaigns that drove measurable customer acquisition.

Implementing a lightweight project intake process is not just about changing your templates; it's about reducing platform friction. The ideal intake system shouldn't require you to build complex integrations, manage external form subscriptions, or force users to log into separate tools just to initiate a workflow.

Start by auditing your current intake pipeline. Identify where the data-entry bottlenecks are, simplify your submission forms to the absolute essentials, and ask yourself: Why aren't we initiating these projects directly inside the enterprise systems we already use?

By keeping your intake structured, lightweight, and platform-native, you transform your project pipeline from a chaotic bottleneck into a strategic engine for growth.

By establishing clean, automated entry points, organizations can stop wasting time on manual data re-entry and chasing missing information for project requests.

Why Enterprise Project Intake Needs a Structured, Lightweight Touch

Ask around and you'll hear Workday PSA described as "the module that tracks projects for accounting." That framing is the first mistake most evaluations make, and it leads to the second one: treating the selection like a back-office decision that finance can make alone.

Workday PSA is not a single product, but rather a solution composed of multiple components (Projects, Project Billing, Services CPQ, Time Tracking, Expenses, parts of HCM and Financial Management).

It is a critical operational system. It determines how your projects get staffed, how your consultants book time, how your customers get invoiced, and how fast revenue lands. Configure it well and your billing close shrinks and your project margins become visible in real time. Configure it badly and your team will struggle and your customers see the evidence on every invoice.

That's why the selection of Workday PSA is not a finance or IT decision alone. It is a strategic decision for your services business. The right choice depends on how your services business operates, not on what features are on the product roadmap.

An operations system wearing a finance badge

Here is the actual value chain for service-based organizations: a project gets quoted and staffed, people enter time against it, that time flows through billing rules into an invoice, and the invoice drives both cash and revenue recognition. Every link in that chain is PSA.

While finance often drives the rules and policies as it related to billing, the impacts are rarely contained to finance. A wrong billing rule shows up as a dispute on a customer invoice. A missing cost rate shows up as a project that looks profitable until month end. A staffing mismatch shows up as a delivery problem before it ever shows up in a report. When you evaluate Workday PSA, you are choosing the system your delivery organization runs on, not a ledger add-on.

Three things stand out after years in the product.

First, project billing. Time and materials, fixed fee, milestones, and rate hierarchies are all native, and they connect directly to customer contracts and revenue recognition. There is no integration to reconcile WIP between the project system and the billing system, because they are the same system and auditable in real-time.

Second, one data model across HCM and Financials. The worker, their cost rate, their role, the project, the contract, and the invoice all live in one place. Firms running standalone PSA tools spend real money keeping worker, supervisory assignment and rate data in sync. In Workday that problem does not exist.

Third, enterprise-grade security. Role-based access means a project manager sees their projects and nothing else, a resource manager sees availability without seeing margins, and finance sees everything. Everything stays in sync even after a reorganization or an acquisition. In a 5,000-person organization, that matters more than any single feature.

Workday PSA is not a universal answer, and pretending otherwise is how implementations go sideways. Be honest about these gaps up front:

If two or more of these describe your business, look hard at alternatives before defaulting to what came with your Workday contract.

It only works if you design it cross-functionally

The single biggest failure mode I see has nothing to do with features. HR configures workers for HR's purposes. Delivery sets up projects for delivery's purposes. Finance builds contracts and billing rules for finance's purposes. Each piece is fine in isolation, and the whole does not work: time comes in against projects that cannot bill it, rates are missing where margin should be, and PSA revenue stops matching billing.

Because PSA sits across HR, delivery, and finance, you have to design the full flow, from opportunity through staffing to invoice and revenue, as one process with all three functions at the table. You need people that understand each aspect and can think through the implications of each configuration decision. If you do not have that, you will not get the benefits of PSA, and you will be frustrated by the overhead.

Workday Services CPQ is the specialized front piece of that flow. It generates the project structure, staffing plan, and billing schedule directly from the quote. The deal sales sold becomes the project delivery runs and the schedule finance bills, without anyone re-keying it. For services organizations serious about Workday PSA, it is the component that closes the loop between selling the work and getting paid for it.

The takeaway: if you run a services operation of real size on Workday Financials and HCM, PSA is probably the right backbone. Evaluate it against your specific use cases, not a feature checklist, and know exactly what you are bolting on for change orders, materials, or scheduling before you commit.

Weighing PSA for your organization? If you want a PSA Readiness Assessment, 

Workday PSA explained by a practitioner: what it does well, and how to tell whether it fits your services business.

What Is Workday PSA and Who Should Actually Use It?

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.

 does and you'll hear about the general ledger, AP, expenses, and reporting. Billing rarely comes up. Not every Financials customer uses it to the fullest extent, so it sits quietly in the platform, treated as a niche module rather than core finance.

That framing is a mistake. For companies that use it, Workday Billing is a critical cog in their monetization machine. It is as strategic as their Go-To-Market plan and it can be the enabler to opening new markets.

Plenty of organizations run Workday Financials without ever leaning on Billing. They invoice from a separate system, push receivables in through an integration, or live in a world where billing is genuinely simple. For them, the GL is the center of gravity and Workday Billing sits idle.

But even those customers can find uses to optimize their financial operations. Whether this is a payment plans for struggling customers, recurring rent collections or simply cash sales. Workday Billing can close gaps elegantly and without much fuss.

For the companies that use it, it's operational

For a company that bills through Workday, billing is an operational function, not a back-office formality. It touches the customer directly, it feeds revenue and cash, and it shapes the numbers your leadership reports every month.

That means your billing configuration has to mirror your business, specifically:

Billing is where strategy meets the invoice. If the configuration can't flex with how you price and package, it quietly becomes the thing that slows the business down.

Two companies can both say they "use Workday Billing" and mean completely different things. The depth runs along a spectrum:

None of these is wrong. At the end, the system needs to support accurate record keeping, reducing revenue leakage and provide the data for strategic decision making. Because Workday Billing is fully integrated in the Workday Financial Management framework and requires no sub-ledger configuration, you receive immense benefits without adding more integration overhead.

Add to this the need to adjust to changing business models. When your sales strategy pivots, you want to have a complete Billing solution that can go with you wherever your sales team goes.

For professional-services firms running Workday PSA, billing stops being a finance-only concern. PSA extends Workday into delivery: resource management, project staffing, time and expense, and project billing. The work your consultants log becomes the invoice the client pays.

That connects operational data straight to revenue. Bill rates, project contract terms, and revenue recognition all have to agree across project delivery and finance. When PSA and Billing aren't configured to line up, you get the classic symptom: project revenue that doesn't match what you billed, and a month-end spent reconciling instead of closing. Done well, the same setup gives you margin visibility by project that a generalist implementation never delivers.

The takeaway is simple. If you bill through Workday, treat Billing as an operational system that has to reflect how you sell and adapt as that changes, not as a module you configured once and forgot.

Not sure your billing setup matches how your business actually sells? 

Workday Billing is not used by every customer, so it gets overlooked. For those that run on it, it is a core operational engine tied to how they price and sell.

Workday Billing: The Operational Half of Financial Management

Why Workday Billing Is Harder Than It Looks

Workday Billing demos beautifully. A clean contract, a tidy invoice, a schedule that bills on the first of the month. Anyone watching the sales cycle walks away thinking billing is the easy part of the Financials footprint.

Then go-live arrives, real contracts land in the system, and the gap shows up. The reason Workday Billing is harder than it looks has nothing to do with the software being weak. It is that billing sits at the intersection of how you sell, how you deliver, and how you recognize revenue, and those three rarely agree.

The demo is clean. Your contracts are not.

In a demo, one customer buys one thing on one schedule. In production, a single customer contract might carry a fixed fee, a usage component, a milestone deliverable, and a renewal that overlaps the prior term. Each of those needs its own billing schedule, its own revenue treatment, and its own handling at period close.

Workday can model all of it. The catch is that the configuration choices get made early, often during implementation, by people who have not yet seen what month nine looks like. Billing schedules, contract line types, and the link between billing and revenue are set once and then quietly shape every invoice for years.

Here is a common one. A SaaS contract renews mid-quarter with a price uplift while the original term is still billing. If that contract was built as a single line rather than two, the uplift either bills wrong or forces a manual credit and rebill every cycle. Small modeling decision, recurring monthly cost.

Most of the pain clusters in a few predictable places. If you are reviewing your own setup, start here:

None of these are exotic. They are the everyday reality of running billing for a business with more than one product and more than one customer type.

Plenty of teams treat their Workday Billing implementation as finished the moment the first clean invoice goes out. The system is live, so the project closes. The trouble is that billing complexity is revealed over time, not at go-live. The edge cases that matter show up at the second renewal, the first acquisition, or the quarter a new product line launches.

This is the configuration debt that builds quietly. Research on finance transformation consistently finds that a large share of ERP investments fall short of their expected value, and billing is a common place where that shortfall hides (Source: 

) . The software is capable. The configuration just never caught up with how the business changed.

If Workday Billing feels harder than the demo promised, that is not a sign you chose the wrong platform. It is a sign your contracts, your delivery model, and your revenue rules are more specific than any demo can show. The fix is rarely a new module. It is matching the configuration to how you actually bill, and revisiting it as the business moves. A short review of how your live contracts are modeled today, schedule by schedule, usually surfaces the worst offenders in an afternoon. That is the cheapest place to start.

Working through this in your own tenant? 

Workday Billing demos clean but breaks on real contracts. Here is where the complexity actually hides, and what 'done' really takes.

When a sales cycle for an enterprise software solution concludes, there is a euphoria amongst the business leaders where they can see their vision come to life. Business transformations that are long overdue appear to be within grasp.
Soon after, though, when implementations begin the stark reality sets in where tight budget, organizational inflexibility and technical limitations are slowing down any dreams.

What drives those headwinds and how can organizations prepare to be successful?

When executives evaluate project success, they compare it to their expectations. Going into a large enterprise software implementation, the drivers are frequqntly business outcomes (such as cost to operate, time to market, regulatory compliance) or technical changes (retirement of legacy systems, reduction in cost to serve, gaps in security and resilience).

The value of the implementation needs to be documented at every stage and measured regularly. Too many times expectations are unspoken and assumed. This can lead to delay in decision making and confusion about direction and prioritization.

Not many organizations are prepared for a transformational implementation.

Here are a few reasons where things can go wrong on the organizational side:

Choosing the right solution and making the best of what was purchased is key to achieving results.
Here are a few reasons where things can go wrong on the organizational side:

There are a few clear learnings that apply to addression most of the above reasons:

When the glow of the sales cycle turns into the duldrum of implementation reality.

Why implementations fail to deliver value

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