AI in workforce planning should not just predict attrition.
It should connect attrition risk back to headcount planning, hiring assumptions, and forecast impact.
I tested this using Adaptive Planning / OneStream-style personnel data with a simple cloud AI architecture.
What if finance could catch unusual expense transactions before close? I explored an AI architecture using Workday supplier invoice data: export transactions, score anomalies in Azure/AWS, then surface exceptions for review. Workday stays the system of record. Cloud handles AI.
I explored how AI can support variance risk analysis using Workday Adaptive Planning.
Adaptive exports budget and actual data to SFTP.
Azure or AWS validates the data and runs the AI/ML logic. The prediction output is loaded back into Adaptive for dashboards and finance review.
Most AI demos look simple.
Prompt.
Code.
Output.
But enterprise AI with Workday Finance and Adaptive Planning data is different.
In production, the model is only one part of the solution.
People often think AI/ML means prompt, code, and model output. In enterprise ERP/EPM, that is only the demo.
In production, AI/ML needs process knowledge, finance data, planning data, integrations, mappings, security, controls, governance, monitoring, and business adoption.
Everyone is asking if AI will replace finance teams.
I think the bigger risk is different:
treating AI demos like production-ready finance systems.
This is Part 1 of a short series on what it actually takes to build AI around ERP, EPM, and finance data.
Spent today inside Workday Extend building an FP&A accelerator. Biggest lesson: don’t fight the tool. Extend is built to surface Workday data, not to be an ETL engine. Prism dataset - WQL - grid is the path that just works.
Rolling Forecast with Temporal Fusion Transformer
Many forecasting examples focus on a single time series.
Real planning environments rarely work that way.
In this lab, we built a rolling forecast model across five business units:
• Enterprise
• SMB
• APAC
• EMEA
• Public Sector
The model combines:
• Historical revenue
• Business unit context
• Future calendar information
One of the objectives was to see how forecast quality changes when the model can learn from both past observations and known future inputs.
The next step will be introducing operational drivers such as headcount, pipeline, bookings, and customer growth.
Can transaction descriptions predict the correct GL account?
To explore that question, we built a BERT-based classification model that learns from previously coded transactions.
Examples included descriptions related to:
• Travel & Entertainment
• Software & SaaS
• Payroll & Benefits
• Marketing & Advertising
• Rent & Facilities
Instead of relying entirely on keyword rules, the model learns patterns from transaction descriptions and predicts the most likely GL account category.
We also included confidence scores so lower-confidence predictions can be routed for review.
This lab explores one possible approach to reducing manual coding effort while keeping finance review in the process.
I am building a RAG agent for finance close docs.
Not a generic chatbot.
The test is simple:
Can it answer close process questions using only source-backed citations?
Correct answer matters.
Correct citation matters more.
A confident wrong policy answer is still a failure.