Start with this research
Finance 2030: What to Do This Quarter
Choose what to change this quarter, what can wait and how to know the improvement is working.
Free · No email or app required
For finance teams
Finance strategy. Better technology decisions.
Connect enterprise priorities with better systems, stronger processes and the work your finance team can deliver next.
Explore ERP, planning, close and consolidation, RPA and AI. The research and tools on this page are free.
Research for the decisions on your desk.
System selection, technology cost, change leadership and automation. Open a guide and use the working record inside it.
IT cost optimization · Application rationalization
Find technology costs you can actually remove
Choose an application decision that reduces spend while protecting the work your business needs.
You finish with: A keep, improve, combine, replace or retire decision for one application, with the cost change, timing and owner recorded.
ERP · Planning · Close and consolidation
Test what your finance system can do
Turn a business requirement into a demonstration you can compare across your current system and shortlisted alternatives.
You finish with: A specific demo request and a record of what works, what costs extra and what remains unproven.
Change management · Leadership
Turn a system change into work your team can do
Explain the change through the task people will perform, the support they need and what managers will do when work gets stuck.
You finish with: A short team change brief with one practice task, an owner for support and a check that the new way works.
Automation · RPA · AI
Choose the right mix of rules, RPA and AI
Match each step to the capability it needs, then connect the steps without losing control of the result.
You finish with: A workflow with a clear job for existing software, RPA, AI and the person responsible for approval.
Technology roadmaps · Finance systems
Decide whether to consolidate your ERP systems
Take the two systems the business is arguing about, start from the result the business needs, test what each route can deliver and what each cannot, separate the differences that must stay from the ones that accumulated, put both routes and their sequence on one cost timeline, and ask for one decision with the trigger that reopens it.
You finish with: One consolidation decision with the business result it serves, the differences that stay, the routes and their sequence costed on one timeline, the dependency outside the team's control, the decision requested with its conditions, and the condition that reopens it.
AI and automation · Workflow decisions
Decide how much a workflow step should do on its own
Take one step in a workflow the business already runs, most of it already automated, where someone has proposed letting an AI agent act. Decide what a rule can settle, what an assistant can propose, what a person still checks or decides, how exceptions come back, and which old work stops. Finish with one bounded decision, not an upgrade.
You finish with: One workflow step with the task defined, the volumes counted on one unit of work, the rule that settles part of it, the assistance that proposes the rest, the human check that stays, the exception path, the work that stops, and the defined subset, evidence and authority under which the step may be allowed to do more.
Organization design · Finance systems
Decide who owns finance's technology work
Decide who owns one finance capability, what each person may change and how the work will get done. Use the example to agree responsibilities across finance, IT and the teams providing the data.
You finish with: An ownership decision covering responsibilities, authority, available time, handoffs and the conditions that would make you revisit it.
Finance priorities
Which Finance Problem Should We Address First?
A high score is useful only if the conditions behind it are visible. Check the measure, decision rights and review capacity before choosing the first improvement.
You finish with: A shortlist checked against three things: how you will measure the improvement, who can make the required decisions, and whether your team has time to review the remaining work. Unanswered questions stay visible.
01
Improving planning and forecasting
What you finish with: A forecast improvement brief that connects a business driver to the required outputs, system capability and next action.
Start with a decision the forecast needs to support. Trace where assumptions are collected, changed, reconciled and approved. Use the brief below to identify one improvement in your planning process or application.
Your forecast improvement brief
Forecast improvement brief
- Decision the forecast must support:
- To complete
- One driver to update (for example, volume, price or headcount):
- To complete
- Source and owner of the current assumption (as of date/time):
- To complete
- Which outputs must change (P&L, cash, staffing or another plan):
- To complete
- Where the team re-enters or reconciles the same information today:
- To complete
- What the existing planning system can already do / who will confirm:
- To complete
- One scenario to demonstrate before changing the process:
- To complete
- Who reviews and approves the revision:
- To complete
- Next action / owner / due date (include any source or figure to confirm):
- To complete
Keep the approved baseline separate. Record changed assumptions and compare the scenario with it.
Use one forecast decision. Keep the brief with the model or plan it refers to.
See an example
A volume change in the forecast
An FP&A team needs to compare a lower-volume scenario with its approved monthly plan. The example isolates volume; real decisions also need the relevant cash, inventory and capacity effects.
- Baseline:
10,000 units at $100 each. Variable cost is $60 per unit and fixed cost is $250,000 for the period.
- Change:
Test 9,000 units with price, unit variable cost and period fixed cost unchanged.
- System requirement:
Create a separate scenario, update the volume driver, recalculate linked outputs and retain the approved baseline and assumption history.
- Next action:
FP&A and the planning application owner demonstrate this in the current system, including approval and the outputs used by business partners.
Check the scenario
- Baseline: $1,000,000 revenue − $600,000 variable cost − $250,000 fixed cost = $150,000 operating contribution in this simplified model.
- Scenario: $900,000 revenue − $540,000 variable cost − $250,000 fixed cost = $110,000.
- The 10% volume reduction lowers this contribution by $40,000. Fixed costs were held constant; do not reduce every cost by 10%.
The useful output is a traceable scenario the team can review. Speed, fewer manual adjustments and clearer assumptions can then be assessed in the actual planning cycle.
Check the simpler fix first
Check driver calculations, connected plans, version control and approval workflow in your existing planning system before adding another spreadsheet or buying another product.
Before you test
- Who owns each assumption and which baseline is approved.
- Whether the required scenario, integration and workflow work in your actual configuration and license.
- Who checks the forecast and the effect on cash or other linked plans before decisions are made.
Use next
- Test what your finance system can do
Turn the brief into a demonstration request for the application owner and any shortlisted supplier; the guide shows this scenario's completed request and the four answers to record.
02
Supporting month-end checks and reconciliations
What you finish with: A short worksheet to sort unmatched items and choose what to tackle first.
Use the unmatched list from your latest close. Grouping items by cause helps you see where a system setting could help and where judgment is still needed.
Sort your unmatched items
Sort your unmatched reconciliation items
Use the unmatched list from your latest close. Count the items in each group:
- A. Same value, different reference:
- ___
- B. Value differs, within a stated tolerance:
- ___
- C. Timing difference across the period end:
- ___
- D. No matching entry:
- ___
1. Start with the largest group:
For A and B, ask your system administrator whether a coding fix or matching rule would help. Confirm the license, costs and approval, name the person who will configure it, and test that it matches the correct transactions. Equal amounts alone do not establish a valid match.
2. Find the cause of missing entries:
For D, check whether the entry was never posted or is in a system the matching process cannot see. Name the person who can resolve it.
3. Check the remaining workload:
- Items still needing review:
- ___
- Minutes to review each item:
- ___
- Review hours = items × minutes ÷ 60:
- ___
- Hours reviewers have available before sign-off:
- ___
Use those counts to ask what AI could help with and what a person would still need to decide. Confirm any reduction in a test before reporting it as a saving.
- Next action:
- ___
- Owner:
- ___
Copy this worksheet and use it with the unmatched list from your latest close.
See how the groups add up
Example: grouping 180 unmatched items
In the same close, 1,240 intercompany lines go in, the owned matching rule clears 1,060 of them, and 180 remain. Sorting those 180 by cause is what tells you whether you have an AI question at all.
| Unmatched, by cause | Items | What closes it |
|---|---|---|
| Same value, different reference | 72 | A coding convention fixed at source |
| Value differs, inside a tolerance | 46 | A tolerance setting in the module you own |
| Timing, either side of the cut | 38 | A person, or a proposal a person checks |
| No counterparty line at all | 24 | Someone outside finance, usually |
| Total unmatched | 180 |
The first two groups contain 118 items. If the license, configuration and testing checks confirm they can be resolved correctly, 62 items remain. At 4 minutes each, that is about 4.1 hours of review, compared with 12 hours for all 180. These figures show the potential reduction; the license and actual results still need confirming. Matching equal amounts alone does not prove the transactions belong together.
Plan a test
Use this checklist after you have selected a specific improvement to test.
The readiness checklist
Month-end reconciliation: what to establish before you automate
One cycle. Fill it in as you go. "Not known" is a correct entry when it carries a name and a date.
The work:
- The reconciliation named, with what it does not cover written down
- Times it runs a year, and working days per run
- Roles and headcount involved
The measure:
- One measure that must change, pulled from a report rather than estimated, with the date it was pulled
- Where it needs to be, and by when
- The guardrail measure that must not worsen while it improves, and the level at which you stop. A speed measure with no quality measure beside it is how a close gets signed before it is right
- What the process costs to run today, with the components shown
What you already own:
- Every capability that could carry part of it, including anything licensed and never configured
- For each: owned, funded, asserted, or not owned
- For each: permitted for this process and this data, not permitted, or nobody has asked
- For each: what it costs to switch on and to run
- Who confirmed the list, and on what date
Where the line falls:
- What the owned capability finishes on its own, in steps
- What is left after it stops: judgment, extraction, or nothing
- If nothing is left, the AI question closes here and the work is configuration
The review point:
- What a person reviews, and at what step
- Who that person is, by role
- What they answer for if the output is wrong, agreed with whoever owns risk and audit rather than decided alone
- The review burden, computed: items per cycle, minutes per item, total hours, and what fraction of one person that is
Before you start the test:
- Baseline measured, not estimated
- Capability, cost, and permission confirmed
- Approval obtained, not just requested
- Every remaining gap has a name and a date against it
Set the outcome and quality checks before choosing the tool.
See an example
Example: a monthly intercompany reconciliation
A manufacturer of roughly 900 people, one enterprise resource planning platform, three legal entities. The controller has been asked to point AI at the monthly intercompany reconciliation after a vendor demonstration.
- The measure:
Elapsed working days from subledger close to signed intercompany schedule, from 3.5 to 2.0 by the March 2027 close. Pulled from the close calendar log, not estimated.
- The guardrail:
Post-close adjustments raised against the schedule, currently two a quarter. Stop and reconsider at four in any quarter. Compressing review is the obvious way to hit 2.0 days and the wrong one.
- What is already owned:
An intercompany matching module licensed in 2024 and never configured, two robotic automation bots for the schedules that arrive as spreadsheets, and a coding standardization that needs no purchase at all.
- What the system handles:
The owned combination extracts, reformats, and matches the exact-value same-currency pairs and produces the residual exception list. It stops at the exceptions, which by definition did not match on a rule.
- What is left:
Judgment. Grouping residual exceptions by probable cause and proposing the likely counterparty match for near misses. Two capable accountants can reach different defensible pairings, which is what makes it judgment rather than extraction.
- Supporting evidence:
A comparable unit. Another entity configured the same module for customer receipts in 2025; its elapsed time fell from 4 days to 2.5, and the residual queue still needed a person.
- What to confirm:
Whether the license tier includes multi-currency tolerance matching, and whether the judgment remainder falls inside the group AI register. Either would move the line, so both are on the page with an owner and a date.
- What it asks for:
Permission to configure a module already licensed, and confirmation that the effort sits inside the existing application budget. No purchase.
The two calculations that decide it
- What the process costs today, on an assumption stated rather than measured. If each of the three people spends the full 3.5 days on this and nothing else, that is 3 times 3.5 times 8, or 84 hours a close. 84 times 12 closes is 1,008 hours, and at a loaded $110 an hour that is $110,880. The team's own time log puts the matching work at about 42 percent of it, which is $46,570. Elapsed days are not staff hours, and full-time effort across the close is an assumption that measured effort would replace.
- The review burden, and the window it has to fit. 180 residual exceptions at 4 minutes each is 720 minutes, or 12 hours. Those 12 hours sit between the residual list appearing and the schedule being signed, which the target compresses to two working days.
- Against assumed capacity, stated as an assumption: one group accountant available for this and little else is roughly 14 productive hours across those two days, so 12 hours of review consumes most of the window and leaves about 2 hours of margin.
A month of notional capacity is the wrong denominator here. 12 hours against 160 makes the review look trivial; 12 hours against a two-day window with one reviewer makes it the binding constraint. On the assumed capacity above the design only just fits, and it does not fit at all if that reviewer carries other close duties, which is the thing to establish before anything is configured. At 2,000 exceptions rather than 180 the same math gives 133 hours, and the design would be impossible rather than tight.
Check the simpler fix first
Check matching rules, coding standards and how schedules reach the system. Fixes here can reduce the work that remains for a person or AI.
Before you test
- Whether the feature is licensed, what it costs and whether it is approved for your financial data.
- Whether the proposed use belongs in your AI or model register.
- Who reviews the remaining items, and whether they have enough time before sign-off.
03
Preparing and checking variance commentary
What you finish with: A sample variance commentary and six checks to use when reviewing your next draft.
AI can help produce a first draft from the variance table, prior commentary and supporting detail. The useful test is whether drafting and review together take less time while meeting your reporting standards.
Variance commentary
Example variance commentary
Facilities (cost center 4120), August 2026.
Variance: Facilities spent $312,400 against a budget of $268,000, an overspend of $44,400, or 16.6 percent (44,400 divided by 268,000).
Drivers: Two items account for $41,900 of that. A chiller repair of $28,600 was posted on 12 August (invoice 88214, approved by the facilities manager under the emergency repair threshold); the 2026 budget for this cost center carries no repair provision, so the full amount is unbudgeted. Contract cleaning of $13,300 was brought forward from September at the supplier's request (invoice 88301, posted 4 August); it is budgeted in September, so this is a timing difference.
Remainder: The remaining $2,500 nets across 14 consumables and minor maintenance lines, none individually above $900.
Timing effect: the August unfavorable variance from cleaning is expected to be offset by a favorable September variance, because the budget is phased in September.
Full-year effect on what is known: the chiller repair and the $2,500 remainder, $31,100 together (28,600 plus 2,500), have no budget offset in the notes provided.
Not stated in the notes: Confirm with the facilities manager before this is issued: whether further chiller work is expected this year (work order WO-4471 closed on 19 August records this repair as complete and says nothing about recurrence), and whether the $31,100 will be recovered elsewhere in the budget.
Use the structure with your own confirmed figures and explanations.
The six checks before it goes out
- 01
Check the totals and variance against the ledger.
For this example: $312,400 − $268,000 = $44,400, or 16.6%.
- 02
Make sure the drivers and remainder add up.
$28,600 + $13,300 = $41,900. The remaining $2,500 is stated separately.
- 03
Trace each driver to a dated transaction.
Include the invoice, work order or other supporting reference.
- 04
Explain timing differences and the full-year effect.
Name the offsetting period and any overspend that remains.
- 05
Confirm explanations, approvals and expectations with the responsible person.
Remove claims that the available sources do not support.
- 06
Have the responsible reviewer sign off.
Keep the existing approval responsibility when AI drafts the commentary.
See an example
Example: forty cost centers, one shared services team
A shared services finance team drafting monthly commentary for forty cost centers, with an assistant included in an office license the organization already holds.
- The work today:
One analyst drafts commentary for forty cost centers, an estimated 25 minutes each to gather the inputs, write and check the draft. The last few are written under deadline and are the thinnest.
- What the draft is built from:
The variance table, the prior month's commentary for the same cost center, and the ledger detail for every movement above the reporting threshold. Nothing else.
- What it may assert, and on what evidence:
Figures and their math, from the ledger. A cause, an approval or a non-recurrence only where a source outside the ledger is supplied with the draft: in the sample below that is a work order number, an invoice with a named approver, and a dated confirmation. Ledger totals alone support none of the three, and a draft given only totals must leave them out.
- What the assistant does:
Produces a first draft per cost center in the house structure: the figure, the variance, the named drivers, the remainder, and the timing or recurrence statement.
- What it must not do:
Assert a cause, an approval, or an intention that is not in the source. This is the failure mode, and it is the reason the verification steps exist rather than a general instruction to check the work.
- Success measure:
Analyst hours on the commentary pack fall below the measured baseline for the same forty cost centers.
- Quality condition:
Corrections raised by the reviewer, and any figure that does not tie to the ledger, do not exceed the baseline. One published figure that does not tie is a stop, not a correction.
- Who decides:
The financial controller, on the reviewer's record of corrections, after one full cycle. The person who owns the draft does not judge their own test.
How the math works
- Before: 40 cost centers at an estimated 25 minutes each to select the inputs, write and check the commentary is 1,000 minutes, or about 16.7 hours a month.
- After: gathering the inputs and running the prompt, about 3 minutes per cost center, is 120 minutes, or 2.0 hours.
- All 40 drafts are then read and edited at 9 minutes each, which is 360 minutes, or 6.0 hours.
- Six of those 40 then need a full rewrite, at 20 minutes each on top of the 9 already spent reading them, which is 120 minutes, or 2.0 hours.
- 2.0 plus 6.0 plus 2.0 is 10.0 hours for the same commentary task, including preparation, running, checking and correction. The 8.0 hours of reading and rewriting is the review capacity the guidance note Which Finance Problem Should We Address First? tests.
- Preparing inputs here means selecting existing pack figures and notes for each draft. Building the underlying variance pack, investigating ledger detail, the controller's approval and publishing sit outside both estimates; none is counted as a saving.
An estimated 6.7 hours a month of difference: 1,000 minutes less 600 minutes is 400 minutes. Every figure above is an estimate, so that difference is a hypothesis until one cycle is measured on both effort and correction rate. A comparison that leaves review time out flatters the tool and will not survive the first question in the room; so does one that quietly excludes the preparation both versions still need.
Check the simpler fix first
Use formulas and templates for the math and formatting. Consider AI for the written explanation, using only supported figures and confirmed causes.
Before you test
- Whether your license includes the assistant and your organization permits this use of unpublished accounts.
- Which source records the assistant can access. Supply supporting detail for any explanation of cause, approval or timing.
- Who checks and signs the final commentary.
Use next
- Run this task in the AI Use Case Dashboard
The variance commentary case: a prompt with a complete sample, the checks a reviewer runs, and an optional one-page proposal.
- Which Finance Problem Should We Address First?
Three readiness checks before committing to this or any other finance improvement: the measure, decision rights and review capacity.
Related resources
Explore the next question.
Continue with finance priorities, technology decisions and AI governance.
- The AI Plan Is Funded. Who Governs It?
A guidance note on the ownership question underneath all three of these: who is accountable for the rules, and whether the evidence can be produced on demand. Nine minutes.
- The AI Use Case Dashboard
Complete tasks for finance and five other teams, filtered by what you want to improve, each with a prompt, a sample and the checks a person runs.
- The AI Decision Diagnostic
Twelve questions on how your organization actually decides, scored across four dimensions, with the moves that follow. Under five minutes, no email required.
- Seven questions before you sign (PDF)
For the conversation after this one, if the answer turns out to be that you need something you do not own.
When you need hands-on help.
Work directly with M. Pact on a specific decision or implementation challenge. M. Pact takes on a small number of engagements at a time.
Discuss your challenge