coins going from disorder to order

Your New Accounting System Isn’t the Risk. Your Old Data Is.

Read time: minutes
Table of Contents
    Add a header to begin generating the table of contents

    Midway through a recent migration, a client’s operations lead flagged something odd. The expense totals by department for a period she had already reviewed had changed. Same month, different numbers. The client, a century-old Episcopal parish in the Mid-Atlantic, had gotten ahead of itself, pulling live reports from the new system before we had finished reconciling the integration feeding it. The person who caught the gap wasn’t an accountant. She was just paying close attention.

    Every nonprofit finance leader I talk to about switching accounting systems asks some version of the same question. How long will it take, and will reports be ready for next month’s board meeting? Fair questions, but the timeline rarely determines whether a migration succeeds. What matters is whether the new reports match the legacy reports, and whether Accounts Payable (AP) and Accounts Receivable (AR) balances by vendor and donor still agree.

    We’ve moved clients off Blackbaud, Microsoft Great Plains, and QuickBooks Desktop, and most recently off Sage Intacct onto Intuit Enterprise Suite, including the parish above, which made the move mainly to cut costs. Other clients migrate for different reasons: fund accounting that’s become a workaround instead of a feature, grant reporting that takes three spreadsheets and a prayer, a board wanting consolidated reporting the old tool was never built to produce. Whatever the trigger, the failure pattern is the same. The organization assumes the data is ready to move just because it’s been working for years.

    It hasn’t been working. It’s been surviving: manual journal entries forcing a report to balance, restricted funds tracked in a side spreadsheet, vendor records duplicated three different ways. None of that shows up as a problem until the new system asks the data to stand on its own.

    What “good” looks like

    A good migration isn’t one that hits its go-live date. It’s one where, six months later, the finance team can pull a prior-year comparison, a funder gets a grant report that ties out, and an auditor doesn’t ask why last year’s numbers don’t match across systems. Good migrations are boring migrations. The story afterward is that nothing broke, not that the team pulled off a heroic save. Here’s what gets us there.

    1. Audit the data before you map it, not while you map it.

    Before an account gets translated into the new system’s structure, we run the historical data through a cleanup pass: orphaned transactions, funds never closed out, chart of accounts entries nobody remembers the purpose of. Mapping bad data faithfully into a new system just gives you the same errors with better formatting. Part of that pass is deciding how far back history needs to go. Nonprofits often want everything, a decade of transactions, every closed grant. Rarely does everything need to live in the live system. We separate what needs to be transactable (open funds, current year detail, anything an auditor will touch) from what just needs to be archived and accessible. That single decision is usually the biggest lever on timeline and cost.

    2. Tie out the subledgers before you trust the ledger.

    Invoice lines and journal entries move over mechanically. What’s hard is getting AP and AR to tie out. A vendor keyed three different ways over a decade means three balances that all have to net to one true payable. On the AR side, the “customer” is often a donor or grantor, and collapsing duplicate records without breaking pledge history or restricted fund attribution is its own project. Many nonprofits also blend grants receivable, pledges receivable, and trade AR into one balance sheet line, and a new chart of accounts that splits them forces a reclassification that has to be tied out before subledger detail will match the general ledger.

    3. Reconcile in parallel, not at the end.

    The riskiest migrations run old and new side by side for one closing cycle and call it validated. We reconcile trial balances, fund balances, and at least one full grant report before anyone treats the new system as the source of truth.

    That discipline is what caught the issue at the parish above. The client had started relying on live reports before we’d finished reconciling the integration between their expense platform and the new system, which was quietly reclassifying transactions by department. Their operations lead caught it during the migration itself, not after. Untangling how the integration was remapping transactions, then rebuilding the affected periods, took somewhere between 50 and 100 hours, all resolved before the parish’s first finance committee meeting under the new system. It didn’t look like a crisis to the client, just a few numbers that looked slightly off, which we chased down until they weren’t. That gap, between how hard something is to fix and how disruptive it feels to the people relying on the reports, is the whole point of reconciling in parallel.

    4. Protect the fund and grant logic specifically.

    General ledger data migrates cleanly. Fund accounting rules, restriction tracking, and grant budget versus actual logic are where systems differ most, and where the real rework happens. Don’t let the finance team discover the gap during a board reporting cycle.

    We sat in on that parish’s first finance committee meeting since the migration closed out. The two members who’d pushed hardest for the switch, and asked the toughest questions throughout, came away satisfied. Every migration sounds simple until you’re the one tying out the subledgers. That’s where the real work lives, and it’s not glamorous. I’d rather spend the hours getting it right quietly than have a client find the problem in a board meeting.

    The takeaway

    Nonprofit leaders don’t lose sleep over which system they’re moving to. They lose sleep over whether the reports they hand a board, a funder, or an auditor next quarter will still be right. A migration is really a data integrity project wearing a software project’s clothes. Treat it that way from the start, and the system change becomes the easy part.


    Looking for more financial insight designed for nonprofit leaders?

    Trustward’s newsletter is brief, practical, and relevant.