What SOX data conversion controls must prove before cutover
When a finance system is replaced, the external auditor will ask one question early: how did you prove that the opening balances and historical records in the new system are complete and accurate? Under PCAOB AS 2110, the auditor's risk assessment lists processing inaccurate data and potential loss of data as IT risks to internal control over financial reporting. A conversion is the point where both risks are most likely to occur, because records leave a system that the organization has tested for years and enter one that has not yet produced a single period-end close. Management owns the answer, and the evidence has to exist before the old system is switched off.
The reason this matters goes beyond the migrated balances. Once data is loaded, it becomes the baseline for downstream automated controls, such as three-way matching, interface postings and calculated reserves. AS 2110 notes that when IT initiates, records and processes transactions, electronic records replace paper and the programs hold controls for relevant assertions. If a mapping error inflates a vendor master or truncates a tax code, every later automated control may run correctly on wrong data. Auditors will therefore look for a documented reconciliation of record counts and control totals from source to target, plus a sign-off by the finance owner of each balance before cutover. Confirm with your auditor which balances and populations they expect to see reconciled, since the scope depends on the accounts and reports in your ICFR scope.
Three things usually make this hard. Volume means that a full population reconciliation can be slow, so teams need to agree in advance which fields are compared in full and which are sampled, and how exceptions are logged and cleared. Mapping errors are common when legacy codes do not have a one-to-one equivalent in the new chart of accounts, so the mapping document should be approved by the process owner, not only by the project team. Late changes are the most dangerous: a rule changed in the final trial load can invalidate reconciliations already signed. Set a freeze date for mapping and transformation logic, and require a documented re-run of affected reconciliations for any change after that date. Also ask whether your implementation partner will prepare these reconciliations, while management and the auditor retain ownership and review.
Which conversions and teams fall inside SOX data conversion scope
Not every migration touches financial reporting, and the ones that do differ in how much control work they create. The cards below separate the data sets that carry balances from the decisions and parties that change the testing burden, so scoping can be agreed with finance and the external auditor before the first load runs.
Ledgers and subledgers
General ledger balances, chart of accounts mappings, and subledgers for receivables, payables, fixed assets and inventory are the core of a financial conversion. Management should confirm which balances and period detail roll into the new system, and whether historical transactions or only closing balances are carried forward. Each balance set needs a reconciliation from the source system to the target that finance signs off, because an error here flows directly into reported figures.
Open items and cutoff balances
Open invoices, unapplied cash, accruals, pending journal entries and in-transit payments are often where conversions fail, because they sit between periods and are easy to drop. Confirm the cutoff date, how open items are identified in the source, and whether they are loaded as balances or as transactions that keep their original aging. Auditors commonly ask how these items were matched after go-live.
Master data feeding financial reports
Customer, vendor, employee, bank account, cost center and product master records determine how transactions post and how reports group them. A changed vendor identifier or cost center hierarchy can misstate a report while the balances still tie. Identify which master data elements drive financially significant reports, and include them in the completeness and accuracy checks rather than treating them as reference data.
Interfaces that carry balances
Bank feeds, payroll, billing, procurement and consolidation interfaces that load balances or summarized postings into the new system are part of the conversion scope when they move financial data. Map each interface to the balances it carries, confirm whether it is retired, redirected or rebuilt, and test that totals agree at the boundary. Interfaces that only move operational data may fall outside scope, which is a decision to document.
One-time versus iterative loads
A single cutover load and repeated trial loads create different evidence needs. Iterative loads produce several sets of reconciliations that must show which version was final and that the production load matched the approved trial. Ask whether the plan includes mock conversions, how many, and who decides which run becomes the basis for go-live, since this determines how much evidence the auditor will request.
Third-party extracts and tooling owners
When a vendor, systems integrator or managed service produces source extracts or runs the load scripts, management still owns the completeness and accuracy conclusion. Confirm who generates each extract, who reviews its record counts, and who maintains the migration tool and its change history. Document these roles in the conversion plan so the auditor can tie each reconciliation to an accountable owner.
How reconciliation of record counts and balances works in practice
The first layer compares how many records left the source system with how many arrived in the target. It is the simplest test, and it catches dropped rows, duplicated loads and extracts that were cut off partway through. The team extracts counts by object (customers, open invoices, journal headers, fixed assets and so on) from the legacy system at a fixed point in time, then runs the same counts in the target after each load. Counts should be taken from the systems themselves, not from the load tool's summary, so that a single reporting error cannot hide a gap.
- Source and target counts by object: Each business object is counted at extract and at load, with the same filters applied to both sides.
- Filter and status parity: Closed, voided or archived records are either migrated or excluded on purpose, and the exclusion rule is written down.
- Repeat runs: Counts are rechecked after every trial load and the final cutover load, since a late refresh can change the population.
- Independent extraction: The person who runs the count is not the person who built the load job where practical.
Check that every object in the migration scope has a count pair, that each difference is explained, and that the reconciliation is retained as evidence with the run date and version of the load.
Counts show that records arrived, but not that the money arrived correctly. This layer ties balances by account and period, and ties control totals such as hash totals or sums of amounts for each batch. For a general ledger, the reviewer compares opening balances by account, period activity, and trial balance totals between the legacy system and the new one. For subledgers such as receivables or payables, the subledger totals must agree with the general ledger control account in both systems.
- Account-level balance tie-out: Each account's opening balance is compared between source and target, in the currency and period the company reports in.
- Subledger to control account: Open item totals are reconciled to the general ledger control account after load.
- Batch control totals: Sums of amounts and item counts for each load batch are compared, so a partial batch is visible immediately.
- Period activity for open periods: Activity in periods still open at cutover is tied out, not only the closing position.
Confirm that differences are either zero or traced to an approved transformation rule, and that the trial balance in the new system is signed by the accounting owner before anyone posts new transactions.
Target systems reject some records, for example when a mandatory field is blank, a code does not exist in the new chart of accounts, or a date falls outside an allowed range. The control question is what happens to each rejected record. Rejects must be logged with a reason, assigned to an owner, corrected or formally excluded, and then reloaded or accepted. A reject queue that nobody reviews is a gap in completeness, because the source balance still exists and the target does not reflect it.
- Reject log with reason codes: Every rejected record is written to a log with the object, source key, error reason and load run.
- Named owner and disposition: Each reject is assigned to a data owner who records whether it was fixed, reloaded or excluded.
- Approved exclusions: Records excluded from the migration are listed and approved by the accounting or business owner before cutover.
- Reject trend review: Repeated reject types across trial loads are investigated for a systemic mapping error rather than handled one by one.
Before go-live, check that the reject log is empty or every open item has a documented disposition, and that the sum of excluded balances is included in the reconciliation so the difference is explained.
Transformation rules change data on the way across: mapping old account codes to new ones, splitting or merging fields, converting currencies, applying default values and deriving dates. Errors here do not show up as missing records, so counts alone will not find them. This layer reviews the mapping specification against the code or tool configuration, tests sample records end to end, and confirms that each rule was approved by the business owner who understands the financial effect.
- Mapping specification sign-off: Each field and account mapping is documented with source, target, rule and approver.
- Sample-based end-to-end tests: Selected source records, including unusual ones, are traced to the target and compared field by field.
- Change control on rules: Any change to a mapping after a trial load is versioned, retested and re-approved, so the final load matches the approved rules.
- Defaults and derivations: Default values and calculated fields are listed separately, since they often carry accounting judgment.
Check that the mapping version used for the final load is the version approved, and that any rule changed after trial loads was retested and signed off before cutover.
How an auditor tests data conversion controls
This table walks through the test steps an external auditor typically performs on migration controls, the evidence each step requests and the findings that most often appear. Read it as a checklist for what your conversion file should prove before cutover, since each row maps to a question the auditor will ask.
| Test step | What the auditor does | Evidence requested | Common finding |
|---|---|---|---|
| Inquiry of the migration lead | Asks who designed the conversion, how source-to-target mapping was approved and which reconciliations were required before cutover | Conversion plan, named owners, mapping specifications and the cutover runbook | Owner cannot explain how reconciliation thresholds were set or who may override them |
| Observation of conversion runs | Watches or reviews a trial load and the final load to confirm the stated steps were followed in order | Load logs, job run records and timestamps for trial and production loads | Final load ran with steps that differ from the approved runbook, with no change record |
| Inspection of reconciliation workpapers | Reads record count and control total reconciliations between source extract, staging and target tables | Signed reconciliation workpapers showing source counts, target counts and any explained differences | Unreconciled differences carried forward into production without a documented investigation |
| Re-performance of balance tie-outs | Selects a sample of account balances and recalculates the tie-out from source to migrated ledger | Trial balance from the legacy system, trial balance from the new system and the tie-out calculation | Tie-out cannot be reproduced from the retained extracts, or the sample reveals unexplained variances |
| Inspection of cutover approval | Checks that the go-live decision was made after reconciliations passed and before users began posting | Signed cutover approval with date and time, and the reconciliation results it relied on | Sign-off dated after cutover, so the approval did not gate the migration |
| Testing of exception handling | Reviews rejected records, error queues and how each was corrected and re-loaded | Exception log, correction approvals and evidence that corrected records were re-reconciled | Rejected records were manually edited with no approval or re-reconciliation |
| Evaluation of access during conversion | Confirms that only authorized personnel could run loads or edit migrated data | Access list for the migration environment and privileged activity logs for the conversion window | Shared or generic accounts performed loads with no review of their activity |
Sequence for building conversion controls before cutover
This sequence turns data conversion from an unplannedload into a documented, testable control. Each step produces evidence that management can show the external auditor, from the agreed scope through to a filed final reconciliation.
Define conversion scope and key balances
Finance and the system owner list which data sets move to the new system, such as open items, general ledger balances, customer and vendor master records, and historical transactions still needed for reporting. They also name the key balances that must agree after conversion, such as trial balance totals and subledger control totals. The step closes with a signed scope document that states what is in and out, and who owns each data set. Auditors look for this document first because it defines what the reconciliations must cover.
Document source-to-target mapping and transformation rules
The conversion team records where each source field comes from, where it lands in the target system, and every rule that changes it, such as code translations, currency handling, date formats and default values. Business owners review the mapping for financial fields, and IT confirms the rules match the build. The output is a versioned mapping specification with named approvers. Changes after approval go through the same review, so the final load can be traced back to an agreed design.
Agree reconciliation criteria and tolerances
Before any trial load, finance and IT agree which checks will prove completeness and accuracy, such as record counts by object, sums of monetary amounts, balances by account and period, and sample-based field comparisons. For each check they set an acceptable tolerance and state who may approve a difference. The output is a reconciliation plan approved before testing starts, so the team cannot later choose checks that happen to pass. Confirm with the external auditor how much detail they expect in this plan.
Run trial conversions with reconciliations
The team runs at least one full trial conversion in a non-production environment, then performs each agreed reconciliation against the source extract and the loaded target. Load logs, rejected-record reports and reconciliation worksheets are saved with the run identifier and date. Where the plan calls for it, the team repeats the trial after fixes so the final results come from a clean run. The output is a set of dated trial reconciliation packs that show each check, its result and who reviewed it.
Resolve and log exceptions
Every failed check, rejected record and unexplained difference is logged with its cause, the person responsible, the fix applied and the rerun that confirmed it. Differences outside tolerance go to finance for a decision, and any accepted difference is approved by the named owner in writing. The output is an exception log that ties each open item to a closed item or an approved exception. Auditors often sample from this log to test whether conversion issues were resolved rather than dropped.
Obtain pre-cutover sign-off from finance and IT
Before the production load, the finance process owner and the IT system owner each sign the final trial reconciliation and the open exception list. Their sign-off confirms the mapping version, the trial run used and the reconciliation results that justify the production run. The sign-off is held with the change or go-live approval for the system. The output is a dated, signed pre-cutover approval that names the conversion run to be executed in production.
Archive the final reconciliation
After the production load, the team runs the approved reconciliations against live data and compares the results to the signed trial baseline. Any difference is handled through the exception process before the business relies on the converted data. The final reconciliation, load logs, mapping version and approvals are stored in a controlled repository with access limited to authorized reviewers. The output is an archived evidence package that lets an auditor trace the migrated balances back to the approved design.
Evidence that passes a data conversion audit
An auditor testing a data conversion looks for proof that the migrated balances are complete and accurate, and that someone approved the cutover with that proof in hand. The cards below cover the artifacts that carry that proof and the habits that keep them current between audits.
Approved mapping specification
The mapping specification shows how each source field, code and balance type becomes a target field in the new system, and who approved it before build. Auditors use it to check that financially significant fields, such as account codes, currency and period identifiers, were carried over with the meaning they had in the legacy system. Check that every version is dated, signed by the business owner and linked to the trial runs that used it.
Trial conversion reconciliations
Each trial load should produce reconciliations of record counts, control totals and account balances between the source extract and the target system. A difference that is not explained is the item an auditor will pick first, so the reconciliation should show every variance and its disposition. Confirm that the trial results are retained with the run date, the extract used and the person who performed the comparison.
Exception log with resolution
The exception log records every rejected or suspended record during trial and final loads, with the reason, the correction made and the approver of that correction. Auditors compare it against the reconciliations to confirm that each exception was resolved rather than dropped. Ask for the log to show who could alter source data during correction and whether those changes were reviewed.
Pre-cutover sign-off
Pre-cutover sign-off is the formal decision that the final conversion results are acceptable and the new system may become the book of record. It should name the approvers from finance and IT, reference the final reconciliations and list any open exceptions with their accepted risk. Keep the signed record separate from project status reports so an auditor can find it without reconstructing the decision.
Backup and restore points before load
Before the final load, take a backup of the legacy data and the target environment so that the conversion can be reversed if reconciliation fails. Verify that the backup can be restored, not only that the job completed, because an unrestorable backup gives no fallback. Tools such as Bareos and restic can produce these points, and their verification features can provide evidence that the stored data was intact.
Versioned documentation and retained extracts
Between audits, keep the mapping specification, reconciliations and sign-offs under version control with a record of who changed them and when. Retain the source extracts used for each trial and the final load so an auditor can rerun a reconciliation months later. Wiki platforms such as XWiki keep page history that can show these changes, but the organization must still decide which versions are the approved record.
Using open-source tools to keep conversion evidence
Auditors testing a conversion want to see which version of the mapping specification was approved, what changed between drafts and who made each change. XWiki is a self-hosted wiki that keeps every change to a page under version control, recording what changed, when and by whom. Users can compare any two versions and roll back to an earlier one, which gives the mapping specification and its sign-off pages a traceable history.
- Specification versions: Keep the field-level mapping, transformation rules and load order on pages whose history shows each revision.
- Change attribution: Each edit records the author and timestamp, so a late change to a balance mapping can be traced to a named person.
- Comparison: Compare the approved version with the version used for the trial load to show what changed in between.
- Rollback limits: Rolling back restores old content, so the organization should record the reason in a new revision rather than erase the trail.
Confirm with your team that the approved version number or revision ID appears in the reconciliation records, so the auditor can match each load to the exact specification it used.
Sign-off before cutover only means something if the people able to approve are the people assigned to approve. BookStack is a self-hosted documentation platform whose user abilities come from the roles assigned to them. Permissions can be overridden per role at the shelf, book, chapter or page level, which lets the organization restrict who can edit or approve the conversion pages.
- Role separation: Keep preparers, reviewers and approvers in different roles so no one can both write the mapping and approve it.
- Page-level restriction: Lock the approval page so only the designated approvers can add sign-off entries.
- Access review evidence: Export the current role assignments on the conversion book and retain them with the sign-off record.
- Scope of control: The platform enforces what users can see and edit in the wiki, not what happens in the ERP itself.
Check that the approval roles match the delegation of authority in your ERP project charter, and that role changes made during the migration are logged and reviewed.
Before a conversion load, the organization should hold a restorable copy of the source and target data so it can recover if the load fails or corrupts records. Bareos is a backup system whose Director schedules and supervises backup, restore, verify and archive jobs, keeps a SQL catalog of backed-up files, and restores files from the current backup or one taken before a given date and time. It is licensed under AGPL-3.0-only.
- Pre-load backup job: Schedule a backup of the source database and target staging area immediately before the load, and record the job ID in the cutover checklist.
- Restore point selection: Use the catalog to restore from the backup taken before a stated date and time if the load must be reversed.
- Verify jobs: Bareos can run verify jobs against the stored backups, which supports the claim that the copy is retrievable.
- Restore testing: Test restores in a non-production environment before relying on them, and keep the test record.
Confirm the retention period and the restore test results with your backup administrator before cutover.
Some evidence needs to show that stored data has not changed since it was captured. restic is a backup tool licensed under BSD-2-Clause. Its check command verifies the structural consistency of snapshots, trees and pack files. With the --read-data or --read-data-subset options, it reads pack files back to confirm that the stored backup data is unmodified.
- Structural check: Run restic check on the repository after each pre-load snapshot to confirm snapshots, trees and pack files are consistent.
- Data read-back: Use --read-data for a full read or --read-data-subset to sample pack files when a full read is too slow for the window.
- Logged output: Save the command output and timestamp with the cutover record so the auditor can see the check was run.
- Interpretation limit: A clean check confirms the backup repository is intact, not that the migrated balances are correct.
Confirm the check frequency and the subset size you chose with the team that owns the repository, and document the reason for each choice.
These tools support evidence. They do not perform reconciliation, and they do not decide whether a conversion is complete and accurate. Record counts, control totals and balance comparisons between source and target must be produced by the migration team, reviewed by finance, and approved by the people the organization has named. Each tool's license also shapes how it can be deployed and supported, so the organization should review the terms before adoption.
- Reconciliation remains manual or system-specific: Counts and balances come from the ERP, the migration tool or reporting queries, not from the wiki or the backup catalog.
- Sign-off belongs to people: The wiki and role settings record who approved, but the approval decision and its basis must be documented in the reconciliation pack.
- License obligations differ: Bareos is AGPL-3.0-only, restic is BSD-2-Clause, XWiki is LGPL-2.1-or-later and BookStack is MIT. Confirm with counsel what each license requires if you modify or distribute the software.
- Independent assurance is separate: Only the external auditor issues an opinion on the controls, and the tools do not replace that testing.
Check with your auditor which evidence formats they will accept before you design the retention and review process around these tools.
What data conversion controls cost to meet
This table breaks down the cost components of meeting data conversion controls under SOX, marking which are one-time and which recur with each later conversion or upgrade. Read it to see who is paid for each component and what to ask for in a quote. No public figures are given here, so the quote and your own environment should set the amounts.
| Cost component | Who is paid or who does the work | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Reconciliation tooling or scripts | Internal engineers or an implementation partner who builds record count and balance comparison scripts | One-time build, then recurring maintenance for each new mapping | Number of source tables, currency and ledger variations, and whether scripts are reused across conversions |
| Trial conversions | Engineering to run test loads, finance to review results against source balances | Recurring for each trial run before cutover | Number of trial cycles, data volume, and how many defects the first trials surface |
| Finance review of reconciliations | Accounting staff who sign off balances, totals and exception logs | Recurring at each conversion event | Number of ledgers, subledgers and open items carried into the new system |
| Cutover approval evidence | Project owners and control owners who document go or no-go decisions | One-time process design, recurring for each cutover | How formal the sign-off chain is and how many approvers the policy requires |
| Evidence upkeep | Control owners who retain scripts, logs, reconciliation workpapers and approvals for the audit period | Recurring through each fiscal year | Retention rules, storage location, and whether evidence is indexed for auditor requests |
| External review of the approach | Independent consultant or internal audit reviewing the conversion design before execution | Usually one-time per major conversion, optional recurring | Complexity of the mapping, prior audit findings, and whether the review is fixed-scope or open-ended |
| Auditor sampling effort | External auditor testing samples of conversion reconciliations and approvals; the organization pays for the audit and supports requests | Recurring each audit cycle | Number of conversions in the period, quality of pre-built evidence, and how quickly control owners respond |
| Rework after failed reconciliation | Engineers and finance staff who correct mappings and rerun conversions | Unplanned, recurs when reconciliations fail | Quality of source data cleansing, clarity of mapping rules, and number of trial cycles completed early |
Who owns the conversion control and who can help
Management owns the conversion control. The company must decide that migrated financial data is complete and accurate, and it must be able to show who made that decision. In practice the control owner is usually a finance or accounting leader who accepts the reconciliations, supported by a data owner for each source and target dataset who understands what the figures mean. IT owns the migration process and the cutover schedule, but IT alone should not approve that balances match.
- Control owner: A named person in finance or accounting who signs off that record counts and control totals agree before cutover.
- Data owners: Business leads for customers, ledgers, inventory or payables who confirm that the mapped fields carry the right meaning.
- IT migration lead: Runs the extraction, transformation and load steps and keeps the job logs and run history.
- Approvers for go-live: Named individuals who authorize cutover after reviewing the reconciliation results, with their approval recorded before the move.
- Exception owner: Someone who decides how unreconciled differences are resolved, documented and carried into the final sign-off.
Confirm that each role has a written owner, a backup and a dated sign-off record before the first trial load runs.
An implementation partner can prepare the tools and evidence that the control depends on. For a self-hosted open-source platform, that typically means conversion scripts, reconciliation templates, test data sets, runbooks and evidence packs. The partner works inside the client's environment and under the client's direction. It does not decide whether the data is accurate and it does not accept the reconciliation on the company's behalf.
- Scripts and load routines: Extraction, transformation and load code that is version controlled and reviewed by the client.
- Reconciliation templates: Predefined queries that compare record counts, balances and key totals between source and target.
- Evidence packs: Organized outputs from each trial and final load, with timestamps, job logs and sign-off placeholders.
- Test plans and runbooks: Documented steps for dry runs, cutover and rollback, owned by the client after handover.
- Knowledge transfer: Training so the client's staff can rerun the reconciliations without the partner present.
Ask for the written scope, the list of deliverables and the handover criteria before work starts. Engagements are typically fixed-scope, so confirm which items are included and which remain with the client.
The external auditor tests whether the conversion control works. Under PCAOB AS 2201, testing of operating effectiveness can combine inquiry of personnel, observation of operations, inspection of documentation and re-performance of the control. For a conversion, the auditor will typically ask to see the reconciliation, who prepared it, who approved it, and whether the differences were investigated. The auditor evaluates the evidence management produced. It does not design the control or prepare the reconciliation.
- Walkthroughs: Inquiry and inspection that show how the conversion process runs from source extract to sign-off.
- Inspection of sign-off: Review of the approvals, dates and exception resolution records.
- Re-performance: The auditor may recompute a sample of reconciliations to check the results.
- Independence limits: Designing, implementing or operating the conversion control is management's responsibility, and an auditor that does so may lose its independence.
- Reliance on partner work: The auditor may review partner-prepared templates, but management must still own and evidence the outcome.
Confirm with your auditor, before the migration starts, which evidence they expect and how they plan to sample the conversion.
Organizations commonly outsource the technical work of a migration while retaining the control itself. The division is usually clear in principle but blurs in practice, so the boundary should be written down. Outsourcing labor does not transfer accountability for the ICFR conclusion.
- Usually outsourced: Script development, environment setup, reconciliation query creation, trial load execution and evidence formatting.
- Usually retained: Choosing which balances must agree, accepting differences, signing the go-live approval and deciding whether to proceed.
- Shared work: Test data selection and mapping review, where the partner proposes and the data owner confirms.
- Ongoing operation: Running reconciliations after cutover for the period the company specifies is usually handled by the client's finance team.
- Quote inputs: Ask the partner to list each task, who performs it, and what evidence each task produces.
Check that your written scope shows who signs each reconciliation and who keeps the final approval record.
Where data conversion controls usually fail
Most data conversion failures are not technical. They come from missing tolerances, weak separation between loading and checking, and sign-offs that arrive after the data is already live. Each card below names one gap, what it looks like in a SOX assessment, and how to close it before cutover.
No documented tolerance
A reconciliation only means something if the team agrees in advance how much difference is acceptable. Without a written tolerance for record counts and balances, a variance is either ignored or argued after the fact. Document the threshold per ledger, per population and per currency, approve it before the first test load, and require that any exception above it stops cutover. Ask the auditor which thresholds they expect to see.
Reconciled by the loader
When the person who ran the load also compares the source and target totals, nobody independent has looked at the result. Assign reconciliation to someone outside the migration build, such as a finance control owner or internal audit, and keep the preparer and reviewer roles separate in the migration tracker. Retain the reconciliation workpapers with the names and dates of both people.
Sign-off dated after cutover
Approval that is signed once the new system is already processing transactions shows that the control did not gate go-live. Make the reconciliation result and the cutover approval separate, dated items, with the approval completed before the production switch. Check that the timestamps in the ticketing or change system match the actual cutover window, because auditors compare them directly.
Unlogged manual corrections
Teams often fix rejected or mismatched records by hand in the target database. If those edits are not logged, the converted balances cannot be traced to their source. Require that every manual correction carries a ticket, the before and after values, the approver and the reason, and that corrections are reconciled again after they are made. Retain the change log as part of the conversion evidence.
Missing restore point
If the legacy data is overwritten or purged before the new system is accepted, a failed conversion cannot be rolled back and the old balances may be unrecoverable. Take a verified, dated backup of the source and of the pre-load target state, and confirm that it can be restored before the load begins. Record the backup identifier and the restore test result in the conversion file so the rollback path is documented.
Questions buyers ask about SOX data conversion controls
How much effort does it take to implement SOX data conversion controls?
Effort depends mostly on how many financially significant data sets move, how many source systems feed them, and how clean the legacy data is. Each conversion needs a defined population, record count and balance reconciliations, exception handling for rejected records, and a documented sign-off. Management owns those controls, so the effort is shared between finance owners who confirm balances and IT staff who run extracts, loads and reconciliations. SEC guidance says management only needs to evaluate the IT general controls that keep other financial reporting controls working properly, so the first step is scoping which conversions touch reported balances. Ask any partner to size the effort from a written list of data sets, sources and reconciliation points rather than from a general estimate.
How long should a team plan before cutover for conversion controls?
There is no fixed duration in the researched facts, so the honest answer is that the schedule follows the conversion plan. Teams usually need time to define reconciliation rules, run at least one trial load, investigate differences, and repeat the load until the reconciled results are stable. Each trial produces evidence that auditors may inspect, so every run should be logged with its date, the data set, the reconciliation results and the people who reviewed them. Ask a partner to show how the trial cycles, approvals and final cutover sign-off map onto your go-live calendar, and confirm the timeline in writing before work starts.
What does the work need from finance and IT teams?
The work needs two kinds of input that cannot be outsourced. Finance must define what correct means for each balance, confirm the control totals and approve reconciliation differences, and sign off that the migrated balances are accurate before cutover. IT must provide source extracts, load logs, interface mappings and access records for the people running the migration. Both teams should agree on who reviews each reconciliation and who can approve exceptions. Under PCAOB AS 2110, auditors look for processing of inaccurate data and loss of data as IT risks, so the reviewers must be able to show they examined the results, not just received them.
Can our own team run SOX data conversion controls in-house?
Yes, many organizations run these controls in-house, provided the people involved understand both the data and the control design. The question to answer is capacity and independence. The team that builds the load should not be the only team that approves its reconciliation, and the reviewers need enough accounting and system knowledge to challenge differences. Ask whether the internal team has done a reconciled migration before, whether it can document each run, and whether an independent reviewer is available. An outside implementation partner can prepare systems, scripts and evidence templates, but management keeps ownership of the controls and approvals.
What drives the cost of conversion controls?
The main cost drivers are the number of financial data sets, the number of source systems, the volume and quality of legacy data, and how many trial loads the reconciliations require. Costs split into one-time work, such as mapping, scripting, reconciliation design and testing, and smaller recurring work if the same process is reused for later conversions or upgrades. Cost also rises when reconciliations are performed manually, when evidence is scattered across email and spreadsheets, or when the sign-off trail is incomplete. When requesting a quote, ask for line items by data set, the reconciliation method, who performs each step, what evidence is retained, and what is excluded, such as external auditor fees or licenses for the target platform.
How is a partner's work kept separate from the auditor's testing?
A partner prepares systems, reconciliation procedures and evidence, while management owns the controls and the external auditor independently tests them. DeployOpen does not issue audit reports, attestations or certifications, and auditors perform their own testing under PCAOB AS 2201, which describes tests of operating effectiveness through inquiry, observation, inspection of documentation and re-performance. To keep the roles clear, the partner should deliver a written scope, documented procedures, and evidence packages that management reviews and signs. Management should decide what the auditor receives, and the auditor should be told in advance which conversion activities are in scope. Confirm these boundaries with your external auditor before the engagement starts.
What evidence should a conversion reconciliation keep for the auditor?
Keep evidence that lets someone re-perform the reconciliation and see who approved it. For each conversion, retain the source extract with its record count and control totals, the load log from the target system, the reconciliation output comparing counts and balances, the list of exceptions with their explanations, and the signed cutover approval. Version the reconciliation scripts and store them with the run records. A documentation platform with version history, such as XWiki, can record what changed, when and by whom in procedure pages, which helps show that approved steps were followed.
How DeployOpen prepares data conversion evidence
DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, including the conversion work that moves financial data into new systems. We prepare the reconciliations, test records and sign-off trail that management and the external auditor can inspect, while your organization keeps ownership of the controls and the conversion decisions.
How we scope
- Agree in writing which financial data sets, source systems and target systems the conversion covers.
- Define reconciliation points such as record counts, control totals and key balances for each migrated data set.
- Name the roles that approve mapping rules, reconciliation results and the cutover decision before work starts.
How we build
- Document field-level mapping and transformation rules so each conversion step can be traced and repeated.
- Run trial conversions and compare counts and balances against source extracts, logging every variance and its resolution.
- Retain conversion scripts, run logs and reconciliation workpapers in version-controlled, access-restricted repositories.
How we hand over
- Deliver a conversion evidence pack with reconciliations, exception logs, approvals and rollback plan for your auditors.
- Record the cutover sign-off sequence and confirm that approvers met the criteria set during scoping.
- Walk your finance, IT and internal audit teams through the evidence so they can explain it to the external auditor.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- Confirm with your auditor which conversion evidence they expect before the engagement is scoped, since requirements vary by company.
- Ask for a written scope and quote before work begins, since DeployOpen does not publish a price list.
