AI Vendor Exit Plan for CPA Firms: What Must Move

Before judging a vendor handover, use the CPA readiness worksheet and four pilot gates to document access, review ownership, escalation and baseline evidence. A high score does not authorize production actions.

If you are a CPA managing partner or CAS leader, start with the workflow that would hurt most to lose. A monthly close exception queue and an unsent billing batch need different handover evidence. Neither is recovered merely because the vendor delivered a folder of PDFs.

Book a discovery call if you want to turn that dependency into a concrete implementation decision. That call is the next step throughout this guide; neither it nor any assessment that follows certifies a vendor or promises that every proprietary system can be migrated.

What must move when an accounting AI vendor changes?

Move the operating context, not just the output. A transaction listing tells the replacement team what exists. It may not tell them which items are unresolved, why one invoice is on hold, what the reviewer approved, or which recurring rule should apply next month.

The CPA.com AI solution due diligence guide asks firms to examine discontinuation, data and log exports, ownership, deletion and continuity when a model provider changes. Its questions are a starting point for evidence gathering, not a guarantee that a vendor has those capabilities.

A separate Morgan Lewis analysis of AI exit rights distinguishes customer data, customer-developed artifacts, outputs and provider obligations. It also describes practical portability substitutes when a proprietary model cannot move. That is the right distinction: retaining enough to continue a workflow does not necessarily mean taking the provider's model or rebuilding its product.

Use this handover inventory for one workflow. The categories are a Fixed Labs implementation recommendation, not a mandated standard.

Do not export credentials alongside client records. Identify the authorized administrator and the required access change; provision or transfer access using the approved mechanism. A handover inventory should contain the responsibility, not the secret.

Separate what you own, can export and can reuse

These are three different questions. Contractual ownership does not establish that an export exists. A readable export does not establish that the next platform accepts it. And a technically usable file does not establish that your firm has the right to reuse every item inside it.

Ask counsel to review the relevant rights, client obligations, retention requirements, licensed material and termination terms. Ask the implementation team to demonstrate readability and continuation. Neither role can substitute for the other.

The AI Accountant's portability discussion frames a useful practitioner question: can the firm take its instructions with it? Our narrower addition is to make those instructions one row in a handover register—and require an owner who can use them. This guide does not adopt that article's vendor-specific feature assessments.

Bring-your-own-cloud and bring-your-own-key are also separate decisions. The former concerns where infrastructure runs and who operates it; the latter concerns model-provider credentials and billing. Neither, by itself, answers whether rules, logs, approvals or unfinished work can be exported. Verify each capability and responsibility independently. This is procurement guidance, not a claim that Fixed Labs or a particular product supports a deployment mode.

Use the twelve-row handover register before the demo ends

Ask the provider to populate an evidence register, then inspect what is missing. A yes/no questionnaire often stops at assurances. A register forces the conversation down to a file, an accountable recipient and a specific use.

This guide comes with a downloadable handover register. Its twelve rows cover source records, document references, procedure, rule library, field mapping, schedule, exception definitions, approvals, action history, open work, access transition and retention/deletion. It uses sample data, no client records or credentials.

For every row, record whether the item is required for the proposed cutover, whether evidence is available, the readable artifact reference, the responsible continuation owner, and the expected use. If a row is not applicable, explain why. An access-transition row names the plan and responsible administrator; it never stores an API key or password.

The completeness checker reads that CSV and reports which required rows lack available evidence, an artifact reference or an owner. It does not open the referenced files. It does not establish rights, validate an export, authenticate a system or prove recovery. Those checks require separate evidence.

Download the completed register to compare the declared evidence changes. Run python3 check_handover.py handover-register.csv from the directory containing both downloads. The evidence files named in the register are examples and aren’t included in the download.

The saved execution results record both sample states. We ran the check on October 11, 2026. It checks declared completeness; it doesn't test a migration or prove that twelve rows cover every firm's obligations.

A complete register can still conceal an unreadable export, a stale rule, an omitted approval or a recipient who lacks access. Treat COMPLETE as permission to inspect, not permission to switch.

Rehearse continuation without double-running consequential work

Choose a bounded, authorized sample and a named reviewer. Establish the last confirmed action before introducing a replacement operator or system. Then ask that replacement to reconstruct the state from the packet and describe the next permitted action.

For an invoice-drafting workflow, for example, the packet might show that an invoice is prepared but unsent, one adjustment remains unapproved and the next owner is the billing manager. The useful rehearsal is whether the replacement preserves that hold—not whether it can create another invoice quickly. Never permit two operators to send or post the same work independently merely to make a migration comparison.

1. Read the source references and verify the sample's identity and scope in the authorized environment.
2. Inspect the procedure, rule version and open-work state. Identify ambiguity before acting.
3. Confirm that approvals and holds remain distinguishable from drafts and suggestions.
4. Have the replacement describe or perform only the authorized, bounded continuation step.
5. Record the readback, reviewer disposition, missing evidence and remaining dependencies.
6. Decide whether to retain the current workflow, repair the packet, narrow the transition or proceed to a separately approved cutover.

Use the AI pilot acceptance decision record for the subsequent go, hold or stop decision. This exit register answers a different question: do you have enough handover evidence to attempt the continuation rehearsal?

Put responsibilities and transition limits in the deal

Name the deliverables, recipient and timing before dependency grows. Do not assume that a helpful demo means the same assistance will be available after cancellation or a service disruption.

Define the export formats and completeness criteria; who prepares and receives them; the transition window; assistance scope and charges; responsibility for rebuilt integrations; continued availability during transition; and when retained copies are deleted, subject to applicable obligations. Morgan Lewis discusses these as provisions to consider, not universal terms every vendor must accept.

Ask about ordinary termination and an unavailable-provider scenario separately. A process that requires the departing vendor to run a custom export may be adequate for a planned switch yet insufficient if the provider cannot help. Determine what authorized, current evidence the firm already holds and what it can realistically maintain. Do not promise uninterrupted service based on a contract alone.

When an exit plan should change the buying decision

Keep a workflow in a smaller pilot when the provider cannot identify pending work, explain the current instructions or produce the agreed evidence. A strong business case does not make those gaps disappear. The CPA readiness scorecard helps assess the wider procedure, input, review, access and measurement foundations.

There are also legitimate reasons not to demand full portability. You may be buying a proprietary capability whose internal model or implementation is not yours to take. A bounded drafting aid with retained outputs and a workable manual fallback may need less transition machinery than a recurring cross-system workflow. Document the limitation and price the rebuild; do not rename it portability.

Assess the cost of maintaining the packet too. Capturing every trace forever is not a sound default. Determine which evidence is needed for continuity and applicable obligations, what can be minimized, and who updates it when a rule or application changes. For a business case, use the review-cost sensitivity model, but don't treat its hypothetical results as measured savings.

Fixed Labs provides assessments and implementation advice. We recommend making one workflow's exit evidence part of the assessment before broad deployment. Bring the workflow description, its approved controls and a redacted vendor handover example—not confidential client files or credentials. Book a discovery call to start identifying the gaps, responsibilities and next bounded validation step.

Before choosing the next implementation partner, use the CPA AI consultant reference-call and handover checklist to ask how a replacement operator will continue held work. Put instructions, account control and open dependencies in the proposed deliverables before comparing fees; a transition promise without an acceptance owner remains unresolved.