What ERP Implementation Backfill Means
ERP implementation backfill is added finance capacity that covers your team’s recurring work while your own people run a system change. It isn’t a permanent hire, and it isn’t the implementation consultant.
Those three roles sit in different places on the project. An implementation partner configures the software. A permanent hire solves a permanent gap. A backfill covers a defined list of recurring work through a project peak, so the people who hold the institutional knowledge can be released to the project without the close slipping.
Federal practice uses nearly the same vocabulary. GAO’s 2026 review of Homeland Security’s financial system modernization notes approvingly that one component’s plans include “SMEs and backups to support implementation processes, including design, testing, and cutover.” The leading practice isn’t just naming your subject matter experts. It’s naming who covers for them.
Backfilling finance roles during ERP implementation works in two directions.
- Backfill the day job. An outside professional takes the recurring work in the system you’re still running. Your subject matter expert goes to design sessions, mapping decisions, data validation and testing.
- Support the project. The outside professional takes project tasks, and your in-house team keeps the close.
The first is usually the stronger structure, for one specific reason. A backfill covering the legacy day job doesn’t need to know the new system at all, because the work sits in the system you haven’t turned off yet. The project work depends on history that lives in people’s heads. What the old system does on the back end that nobody wrote down.
Buy the replaceable hours. Keep the unreplaceable knowledge on the project.
Project support is the right call in narrower cases, and the sections below say which. Project plans often label either arrangement ERP implementation staff augmentation, the same idea described from the project manager’s side. Choosing the system and running the migration is a separate decision, and indinero already publishes on deciding when to migrate accounting systems, so this piece stays on the staffing question.
When a System Change Strains the Finance Team
A system change strains the finance team when project dates and the close calendar land on the same people at the same time. Neither one moves.
The scene is familiar. The controller is in a mapping workshop on day three of the close. The senior accountant who owns the bank reconciliations is the only person who can tell the integrator whether a clearing account is still in use. Nothing has gone wrong yet, and the close is already late.
Five loads arrive at once, and only one of them is the project work itself.
- Subject matter expert time, the largest and least visible. Design workshops, dimension decisions, approval workflow design, reporting requirements and test script review all need the person who knows the current state. That’s usually the person who owns the close.
- Clearing open items before migration. Aged receivables nobody has chased, aged payables that are really credits, unapplied cash, unreconciled bank and clearing accounts, balances sitting in suspense. The work exists only because of the project, it happens in the legacy system, and it has to happen before the data moves. If the books need correcting first, that’s catch-up bookkeeping, and it’s much easier before cutover than after.
- Testing your team alone can judge. User acceptance testing means something only when the tester can recognize a wrong result. That competence sits in accounting, not in IT and not with the integrator.
- Schedule compression. The same GAO review records one component using older data for its mock testing because the program’s schedule had been compressed. That’s what happens when capacity runs out. The validation step technically happens, on data that no longer represents reality.
- The first closes after go-live. New reports, new mappings, new approval paths, exceptions to chase and a legacy-to-new comparison to maintain. Demand doesn’t drop at cutover. It peaks just after it.
Which people are hardest to release follows from that list. The person who owns the close carries procedural knowledge nobody wrote down, against a hard external deadline. The person who knows the chart of accounts and the legacy data is non-negotiable for the project, because no substitute exists, which makes backfilling around them the only option. If role boundaries are blurry on your team, what a controller, a comptroller and a CFO each own is a useful place to start.
Release the knowledge. Backfill the procedure.
Hiring is a poor answer to a project-shaped peak. SHRM’s 2026 recruiting benchmarking, drawn from more than 4,600 organizations, puts the median time to fill at 39 calendar days for nonexecutive positions. Half of searches run longer than that before an offer is even accepted, let alone before the new person is productive. A permanent seat created for a temporary peak is the other half of the problem.
Where Backfill Fits
Backfill fits where your own finance leaders still direct the work. A defined project or a temporary gap that your team scopes, prioritizes and approves is on-demand support, and ERP implementation backfill sits there. A finance function you’d rather someone else ran day to day is a different model, finance as a service, and ongoing strategic financial leadership is CFO services. A system change doesn’t move a company from one model to the other.
How to Scope Backfill Around the Project Plan
Scope the backfill against the project plan’s phases, because finance demand rises and falls with them instead of staying flat. Finance team capacity during system implementation has two peaks and a tail.
Map the work to the project’s phases
Six phases carry different finance loads, and the backfill should follow them.
- Design. Heaviest demand on the people who know the current structure. Chart of accounts and dimension decisions, approval workflows, reporting requirements. The backfill holds the recurring close and transaction processing so those sessions aren’t scheduled against close week.
- Configuration. Lighter finance demand, mostly review and decisions taken in batches. The backfill holds steady on the day job.
- Data migration and validation. The first peak. Legacy cleanup and validation of extracts, mappings and trial balances run at the same time.
- User acceptance testing. The second peak. Scripts need testers who recognize a wrong answer, so the backfill covers the day job while the testers test.
- Cutover. Highest risk, least slack. Transaction cutoff, a clean final legacy close, opening balances and final reconciliations.
- Post-go-live stabilization. The tail most plans underestimate. The first close in the new system, mapping errors surfacing, exceptions to clear.
This is why a backfill shouldn’t be scoped to end on go-live day.
Decide which seat you backfill
Write down both halves of the decision. The seat you cover, and the person you release. Scope the seat and its task list, not the person. Prepares bank and credit card reconciliations. Processes the payables run. Prepares close checklist items in sections A through C. Then name who reviews each one.
Pick the seat with the most documented, repeatable work, because that’s the work that can move. If nothing is written down, the first piece of work is writing the task list, and that’s worth doing whoever ends up covering the seat. Cleanup and execution can sit outside the company. Mapping judgment and approval cannot.
Set access, approvals and review points
Give the least access that does the job. Legacy-only access where the work is legacy. Read-only where the work is review. No configuration access in the new system, no payment release rights unless you deliberately grant them, and no user administration. Least privilege at the start also makes the handback short, because there’s less to revoke. Our guide to security and access when an outside team works in your books covers the mechanics.
Segregation of duties gets harder during a project, not easier. Whoever prepares a reconciliation doesn’t approve it. Whoever enters a payable doesn’t release the payment. The backfill prepares, and your controller or finance leader reviews and approves, including every data validation sign-off. Capacity then steps up through migration, validation and testing, holds through cutover, and steps down across the first closes in the new system.
The close in the month of cutover
The month of cutover is the hardest close of the project, and it’s a controls event as much as an accounting one. Five things land on the same calendar.
- A hard transaction cutoff, agreed and communicated to sales, purchasing, payroll and operations, not just inside finance.
- A clean final close in the legacy system, on the normal calendar. Our month-end close checklist works as a starting template.
- Opening balance validation. The new system’s opening trial balance ties to the legacy closing trial balance, and every subledger ties to its control account.
- A reconciliation of the legacy system to the new one. GAO found that department guidance for the cutover phase “did not include topics such as reconciling data in the legacy system to the new system,” which raises the risk of data errors.
- A log of every manual entry and workaround. Manual journals, spreadsheet bridges, out-of-system payments. These are the items auditors ask about and the items that get forgotten.
Parallel running is a resourcing decision, not a free control. A JFMIP white paper on parallel operation asked whether it is even a desirable transition technique, which is the right question to put to your own team, because running both systems doubles the transaction work for the same people. Targeted parallel validation is the practical middle ground. Re-run a defined set in both systems, one period’s bank reconciliation and the receivables aging, rather than every transaction.
Sign-off on data validation belongs to your own finance leadership. Your controller or VP Finance, with the owner or CFO where governance calls for it, approves the opening balances and the conversion reconciliation. An outside professional can prepare the reconciliation, document the variances and present the evidence. Accepting converted balances is management’s assertion about its own books. The Journal of Accountancy’s case for account reconciliation as a control is the operational version of the same risk. Reconciliations that fall behind during a conversion stop being a backlog and become a control failure.
A fictional worked example
Take Bellhaven Industrial, a company invented here for illustration. Its finance team is five people. One controller, one senior accountant, two payables and receivables specialists and one staff accountant. Through design, migration and testing, the project needs the controller at roughly half their hours and the senior accountant at roughly three quarters of theirs.
That’s about a quarter of the team’s total hours gone from the day job, in the same months the day job grows by the legacy cleanup. Bellhaven scopes two seats’ worth of routine execution, close support and reconciliations plus payables processing, and every approval stays with the controller. The project team doesn’t change. Bellhaven isn’t a client, and the percentages are illustrative rather than a benchmark.
How to Hand the Day Job Back After Go-Live
Hand the day job back by treating the handback as a deliverable, scoped at the start and owned in-house. The reason to define it early is practical. A professional who knows from the outset that they’ll be writing process notes documents as they go, instead of reconstructing undocumented practice at the end.
Four things transfer, and each one gets a named in-house owner.
- Process notes written for the new system. How each recurring task is performed now. Which report replaces which legacy report. Which approval path applies, and which mapping drives which account.
- An open items list with owners and review dates. Unreconciled differences, conversion exceptions, aged receivables and payables that didn’t clear before migration, and mapping errors found during stabilization but not yet fixed.
- Reconciliation notes and workpapers, left in your own files. The opening balance tie-out, the legacy-to-new comparison, the manual entry log and the supporting reconciliations stay in your systems and document store. They’re your audit evidence, and the first thing an audit preparation request list asks for.
- An explicit list of access to revoke. Every account and permission created for the engagement. Legacy system, new system, bank portal, payables tool, document store, reporting layer. Revoke on a date you set, and document the removal with the system owner.
Two sequencing points separate a handback from an abandonment.
Don’t end at go-live day. Stabilization is when mapping errors, broken report logic and bad conversion data surface, which is after cutover. Step capacity down across the first closes in the new system instead of stopping the day the system turns on.
Then reverse the roles before anyone leaves. For the last stretch, your in-house owner runs the task and the outside professional reviews, rather than the other way around. The first close your team runs alone, with no outside hands, is the real end of the engagement. If an item on the handback list has no in-house owner, the handback isn’t finished.
How Indinero’s On-Demand Finance Support Works
Indinero’s on-demand finance support provides access to experienced finance professionals who support specific projects, initiatives or operational needs. No fully outsourced finance function required.
System transitions is one of the service’s own named project types, alongside financial cleanup and reporting improvements. Accounting system transition support is where this topic sits, and the work follows four steps. Define the role. Match a professional who integrates into your existing workflows and systems. Support the work. Scale up or down as the project moves.
Indinero’s professionals work within your existing systems and processes, so your team doesn’t change how it operates to get help. That matters more here than on most topics, because a backfill covering the legacy day job has to work inside the system you’re still running, while you stand up its replacement.
Your company maintains control over priorities and day-to-day management while indinero provides specialized expertise to support your team. You decide what gets worked, who reviews it and who signs the validation off. An indinero controller can take on reconciliations, payables and audit schedules inside your process, while your team keeps its priorities.
Indinero provides CFOs, controllers, accounting professionals and finance specialists, and the mix depends on the need and the scope. When a controller, accounting or specialist seat is empty or a deadline outgrows the team, indinero can match a professional to the role, so you skip a lengthy hiring cycle. Engagements can be short term or long term, and timing depends on the role and scope. As a firm, indinero has maintained continuous operations since 2009 and is SOC 2 compliant (2026).
A system change is one project, and your close doesn’t pause for it. If both are about to land on the same people in the same month, it’s worth a conversation about indinero’s on-demand finance support before the cutover date is fixed. Talk to an Expert, and we’d like to hear how your team is planning to cover the work ahead.
Frequently asked questions
Scoping a backfill around a system change raises the same handful of questions on almost every project. Here are the ones finance leaders ask us first.
Should we backfill the day job or the project role?
Backfill the day job in most cases, covering the recurring close, payables, receivables and reconciliations while your own experts go to the project. The people who know the legacy data, the chart of accounts and the close are the ones design, testing and validation need, and that knowledge can’t be handed over on a deadline. Routine work is far easier to specify, and indinero can match a professional to that seat inside your existing systems and process.
Which finance people are hardest to release for an ERP project?
On an ERP project, the hardest people to release are whoever owns the close and whoever knows the legacy data and chart of accounts. That’s the tension, because design workshops, mapping decisions, testing and data validation need exactly those two, and the close still has a hard external deadline. Send them to the project with nobody covering the recurring work and the close slips.
Does the backfill professional need to know the new system?
Generally no, because a backfill covering the legacy day job works inside the system you haven’t turned off yet. That’s one of the stronger arguments for backfilling the day job rather than the project role, since new-system fluency is a project-team requirement. If your scope puts the professional on the new system after go-live, decide that up front when you define the role.
Who signs off on data validation before cutover?
Data validation sign-off belongs to your own finance leadership, usually the controller or VP Finance, not to an outside professional. A professional brought in from outside can reconcile the accounts, tie out balances and document every exception, and your finance leader reviews and approves. Accepting converted balances is management’s assertion about its own books, and the opening trial balance and legacy-to-new reconciliation are the items that matter most.
What happens to the month-end close in the month of cutover?
The month-end close still has to land in the cutover month, and it usually gets harder than a normal close. A hard transaction cutoff, a clean final close in the legacy system, opening balance validation and a reconciliation of legacy to new all land on the same calendar. Running a defined set in both systems is a resourcing decision, not a free control, so this is the close most likely to need added hands.
Can backfill help clear open items before data migration?
Yes, and clearing open items before migration is one of the better uses of added finance capacity. Aged receivables and payables, unapplied cash, unreconciled bank and clearing accounts and balances sitting in suspense all migrate as bad data if nobody clears them first. Your in-house team decides the treatment for each item and the outside professional does the volume work behind that decision, which is far easier before cutover than after.
