The short answer
Freeze the first-close period and opening baseline, reconcile target activity and external cash, bridge every report to the approved migration boundary, compare expected and actual close dependencies, and classify differences as opening, live transaction, configuration, mapping, timing, presentation, or unknown. Accept the migration close separately from ordinary monthly approval.
Key takeaways
- Go-live does not prove the first live close.
- Separate opening defects from post-cutover activity.
- Accept the period, reports, and unresolved exception ownership together.
Define the first-close proof package
Record period, source closing and target opening baselines, imported and live journals, bank accounts, receipts, payables, owner balances, reserves, deposits where applicable, reports, scheduled jobs, integrations, corrections, and the close calendar version.
Accounting conclusions and regulated account treatment require the responsible qualified reviewer. This page supplies a reconciliation structure.
Classify every first-close difference
| Class | Boundary question | Evidence | Acceptance effect |
|---|---|---|---|
| Opening | Did target begin from approved source close? | Opening batch and cutover proof | Migration defect or approved difference |
| Live activity | Did post-cutover event post once and correctly? | External and target identities | Operational correction |
| Configuration/mapping | Did target rule transform presentation or accounting? | Version and test evidence | Change control and retest |
| Timing | Is the item valid but outside one cutoff? | Timestamps and period rule | Explained carryforward |
| Unknown | No supported bridge exists | Owned exception | Do not accept affected domain |
Issue a separate migration-close decision
State accepted domains, held domains, material unresolved items under the team’s policy, owner-report impact, distribution or payment holds, support dependencies, source-access needs, and the date of the next close check.
Do not retire the source merely because the first close completes; use the separate decommission gates.
Close with a signed first-close bridge and domain dispositions
Name the reviewed population, cutoff, evidence version, decision owner, unresolved exceptions, next checkpoint, and downstream records updated. Preserve the superseded state; a clean current screen is not a substitute for the correction or exception history.
Reopen the record if the population, authority, source version, external outcome, or dependent report changes after sign-off.
Operational checklist
Mark your progress, then save a working copy. Selections reset when you leave this page. A checked box is not an approval or evidence of completion.
☐
Opening baseline frozen
☐
Full close population defined
☐
External cash reconciled
☐
Differences classified
☐
Reports tied to approved sources
☐
Held domains named
☐
Decommission decision kept separate
0 of 7 marked
Edge cases
- Cutover occurred mid-period: explicitly split source and target ownership.
- Reports differ only by definition: retain the comparability bridge.
- First close finishes with manual workarounds: record recurrence and ownership before acceptance.
Sources and references
Follow each source to check the underlying claim. Access checks and professional review are different steps.
Continue the workflow
PMS migration acceptance criteriaProperty-management close calendar dependency registerHistorical report comparability after a PMS migrationSource-system decommission acceptance after PMS migrationRevision history
2026-09-18
Initial Phase 5 operational article with distinct intent, original artifact, source limits, and AI-assisted technical review.