05 Fractional finance lead
The First 90 Days of a Fractional Finance Lead
What a fractional finance lead does in the first ninety days: diagnostic, cash discipline, a close that holds, and a finance calendar for the year ahead.
What this covers
04Finance systems
Implementing the Finance Stack
Selecting the systems is the small part. The order you migrate them in, and what you prove before cutover, is what decides whether the first close on the new stack lands.
Companies rarely get into trouble because they picked the wrong accounting package. They get into trouble because they migrated five systems in the same quarter, cut over mid-period, never ran a parallel month, and discovered when the year-end slips came due that the opening balances were wrong and the payroll year to date figures do not carry. This page is our implementation method: the order the decisions have to happen in, the criteria we score against, the sequence we migrate in, and the checks that have to pass before you rely on the output. We are not a reseller and we do not take vendor commissions, so the selection work below is about fit rather than about a preferred product. Selection and cutover are run by Khaled Hawari, who works day to day in CaseWare and ProFile and has moved acquired entities onto a shared ledger while the reporting calendar kept running. The sequencing below comes from that rather than from a vendor's implementation guide.
ScopeWhat the engagement covers
01Decide the ledger first, because everything else conforms to it
The general ledger is the constraint, not one of five parallel choices. Its data model decides what dimensions you can report on, which decides whether the P&L by service line is a report or a spreadsheet exercise every month. Its handling of multiple entities decides whether a holdco structure consolidates automatically or manually. Its API and export capability decides which AP, expense and payroll tools can integrate without a monthly file dance. So we settle the ledger, and the chart of accounts and dimension structure that sits inside it, before scoring any other tool. Choosing an expense app first and then discovering that its export does not carry the dimension your reporting depends on is the single most common sequencing mistake we are called in to unwind.
02The criteria we score against, which are mostly not features
Every product in this market demos well, so we score against the things that do not appear in a demo. Can you export the complete transaction history, including attachments, in a form another system could read, and what does that export actually look like when you run it. Does it keep an immutable audit trail with a user, a timestamp and a before and after value, and can a user delete rather than reverse. Can you lock a period so nobody posts backwards into a reported month. What dimensions exist beyond the account code, how many, and do they survive an export. Does it handle Canadian payroll and sales tax properly, including provincial variation, rather than through a bolt-on. What are the user roles, and can you grant a role that reconciles without granting one that pays. What happens at ten times your current transaction volume. Price appears on the scorecard, but it is not where these decisions are usually won or lost.
03Migration sequence
We migrate in this order: ledger, then accounts payable, then expense, then reporting, and payroll only at a calendar year boundary. The ledger goes first because everything downstream maps to it. AP goes second because it produces the highest volume of coded transactions and it is where the approval workflow lives, and getting workflow right early removes work from the close immediately. Expense follows AP because it uses the same approval and coding structures and can inherit them. Reporting goes last, on purpose, because a reporting layer built on top of data that is still moving has to be rebuilt. Payroll is the exception to all of this: it is not sequenced by convenience but by the calendar, because year to date earnings, deductions and remittance history have to carry, and a mid-year payroll migration means running two sets of year to date figures through to the following year-end slip filing.
04Opening balances and the parallel period
Cutover happens at a period boundary and never mid-period, because a partial period split across two ledgers cannot be reconciled cleanly by anyone afterwards. Before cutover we validate opening balances line by line against a reconciled trial balance, not against whatever the old system printed on its last day: subledger totals must agree to control accounts, the receivable and payable ageing must agree in detail rather than in total, and any difference is resolved and documented rather than plugged. Then we run one period in parallel, both systems producing a full trial balance, and reconcile them to the dollar with every difference explained. That parallel month costs real effort and it is the first thing that gets cut when a project runs late. It is also the only check that finds the mapping error that would otherwise surface at year end.
05Accounts payable and expense: fix approval before automating it
Automating an approval process that nobody follows just produces faster unapproved payments. So the first step in the AP workstream is defining who approves what and at which threshold, which is the same delegation of authority document the control matrix uses, and only then encoding it in the tool. We route by category and amount rather than routing everything to the owner, because an approval queue that is too long stops being read. Vendor master data is cleaned before migration rather than after: duplicates merged, dormant vendors deactivated, banking details verified for the vendors that account for most of the spend. Expense follows the same pattern, with the coding structure and the receipt policy agreed before the app is deployed, because retraining people on a category structure after rollout is far harder than getting it right once.
06Payroll, and the one migration rule that is not negotiable
Payroll migrates effective the first day of a calendar year, and if that date has passed, it waits. Payroll year to date earnings, deductions, remittance history and the year-end slips all run on the calendar year regardless of when your fiscal year ends, so unless the two coincide this is not the same date as your ledger cutover. Year to date earnings and deductions, remittance history, accumulated vacation and benefit balances all have to carry across, and a mid-year cutover means reconciling two providers' figures for the year-end slips. Before cutover we run a full parallel payroll: same period, both systems, reconciled to the cent on gross, on each deduction, on employer costs and on the remittance total, with any difference explained rather than accepted. Employee master data is verified individually rather than trusted from an export, because a wrong deposit account or a wrong province of employment does not fail loudly, it just pays the wrong person or remits to the wrong jurisdiction.
07Cutover runbook and the support window
Cutover runs from a written runbook with a timeline, a named owner for each step, a go and no-go checkpoint, and a rollback position that stays valid until the parallel reconciliation passes. The old system stays readable, not just archived, for the full retention period, and we take and store an independent export of the full transaction history rather than relying on continued access to a subscription you are about to cancel. After cutover we stay through two full closes, because the first close on a new stack always surfaces something the parallel run did not, usually a report that was silently built on a field that no longer exists. At the end of the second close we hand over the documentation set and the training material, and the system is your team's to run.
OutputWhat you receive
Deliverables
- 01A scored requirements matrix covering the shortlisted products against your criteria, with the reasoning recorded
- 02A chart of accounts and dimension structure designed for reporting by service line
- 03A data migration map, field by field, from the old system to the new one
- 04A validated opening balance file, with subledger to control account agreement
- 05A parallel period reconciliation, reconciled to the dollar with differences explained
- 06A cutover runbook with timeline, owners, go and no-go checkpoints and a rollback position
- 07A user role and permission matrix consistent with the segregation of duties design
- 08An independent export and archive of the legacy system covering the retention period
- 09Written process documentation and training material for your team
- 10Support through the first two closes on the new stack
FAQAsked before signing
FAQ: Finance systems
Do you resell or take commission on any of these systems?
No. We do not have reseller agreements or referral arrangements with finance software vendors, so the recommendation reflects the scoring rather than a margin. You buy your licences directly.
How long does a full stack implementation take?
It depends far more on your calendar than on the work. The ledger cutover has to land at a period boundary, payroll has to land at a calendar year boundary, and we do not run two migrations in the same period. In practice that means the sequence is planned backwards from those two fixed dates rather than from a project start date.
Can we keep our current accounting system and just fix the reporting?
Often yes, and it is worth testing before assuming a migration. The question is whether the ledger can carry the dimensions your reporting needs and whether it can lock a period. If it can, a reporting layer and a tidier chart of accounts get you most of the way at a fraction of the disruption.
What happens to our historical data?
Transaction history is exported independently and archived in a readable form for the full retention period, and the legacy system stays accessible until that archive has been verified. We do not migrate years of detail into the new ledger, because it makes the new system slower and rarely gets used. Opening balances and a defined period of comparative detail carry across.
Our team is already stretched. How much of this lands on them?
The heaviest demand on your team is verification, not data entry: confirming vendor and employee records, confirming the coding structure, and reviewing the parallel reconciliation. We do the mapping, the loads and the reconciliation work. The verification cannot be outsourced, because your team is the only party that knows whether a record is right.
NextThe other engagements
06 Close remediation
Taking Over a Close That Is Failing
Taking over a month-end that has stopped working: triage first, then the suspense and reconciliation backlog, a restatement decision, one clean period.
What this covers
01 Close operations
The Monthly Close, Run as a Service
We run month-end on a fixed twelve business day calendar, with a named owner and a stated dependency behind every step, ending in a reviewed pack.
What this covers
Talk about implementing the finance stack.
Bring the last three periods and whoever currently touches the ledger. An hour is enough to tell you whether this engagement is the right one and what it would take to run it.