Reconstructing Records When the Evidence Was Never Captured

You may reconstruct missing records from surviving secondary evidence, provided every reconstructed record is labelled as reconstructed, dated when it was rebuilt and traceable to its sources. You may not create records that pretend to have been made at the time. The method has four steps. Identify the surviving sources, such as emails, exports, backups, system logs, bank and delivery records and the database of a decommissioned system. Reconcile them against the gap. Produce a reconstruction register showing the source and a confidence rating for every record. Disclose the gap, the method and the remediation to your auditor. Then put auditable capture in place so the gap stops widening from today.

This is general practice from 8+ years of Dynamics 365 Customer Engagement, Power Platform and custom CRM delivery, including data recovery from legacy and decommissioned systems. It is not legal, accounting or regulatory advice. Whether reconstructed evidence is acceptable, and how it must be presented, depends on your regime and your auditor, so agree the approach with them and with your compliance lead before the work starts, not after.

What is the difference between reconstructing a record and fabricating one?

Honesty about when and how the record was made. A reconstruction says: this is what we believe happened, rebuilt on this date, from these sources, with this level of confidence. A fabrication says, or allows the reader to assume, that the record was created at the time of the event.

The practical tests are simple:

• Can anyone reading the record see that it was reconstructed, without having to be told?
• Is the date the record was created the real date it was created, with the date of the original event held separately?
• Does every reconstructed value point to at least one source that existed before the reconstruction started?
• Where no source exists, is the value left blank and the gap stated, rather than filled with a plausible guess?

Anything that fails those tests, such as backdating system dates, recreating signatures or approvals, writing minutes for meetings nobody recorded, or editing surviving documents to match, crosses from reconstruction into fabrication. That is a legal and professional risk far larger than the original gap, and no auditor will thank you for it.

Which surviving sources can records be reconstructed from?

More than most teams expect, although each source proves something narrower than it first appears. Collect and preserve them before anyone starts rebuilding, and record where each copy came from and when it was taken:

• Email and calendars: correspondence, attachments, meeting invitations and replies, with their own timestamps. They show that something was communicated, not that a field held a particular value.
• Exports and reports: spreadsheets, scheduled report files and data extracts people saved locally or in shared drives. They show a state at a point in time, if the export date can be established.
• Backups: database or environment backups restored to an isolated copy, compared against the current data. For Dynamics 365, backup availability windows are limited, so check current Microsoft documentation for what can still be restored.
• System and integration logs: audit history where it existed, middleware and message logs, file transfer logs and application logs.
• Bank, payment and delivery records: statements, remittances, courier and carrier confirmations and signed delivery notes, which come from third parties and are often the strongest evidence available.
• Documents held by counterparties: customer and supplier copies of orders, contracts, confirmations and correspondence, requested in writing.
• A decommissioned system's database: frequently the richest source of all, covered in the next section.
• People: statements from staff who did the work are useful for context, but they are recollection, and should be recorded as such with the date they were given.

How do you recover data from a decommissioned system's database?

Treat it as evidence first and a data source second. Take a copy, record where it came from and its checksum, and never work on the only copy. Restore it to an isolated environment that nobody uses for anything else.

Old systems rarely store data the way their screens showed it. Expect codes instead of labels, status values whose meaning was never documented, soft-deleted rows still present, history tables or change logs that the application used internally, and dates in time zones nobody remembers. Before extracting anything, reverse-engineer the tables that matter, confirm the meaning of each status and code against surviving screenshots, reports or user manuals, and test your reading of the data against a sample of records you can verify from another source, such as a bank payment or a delivery note.

Then extract the records for the gap period with their original identifiers and keys intact, so every reconstructed record can point back to the row it came from.

How do you reconstruct data when reporting from a decommissioned system shows the wrong numbers?

Stop trying to make the total match and rebuild it from the transactions. When finance reporting disagrees with what an old system says, the cause is almost always one of a small set: records included or excluded by a filter nobody documented, duplicates, cancellations or credit entries handled differently, a migration that dropped or transformed rows, cut-off dates applied inconsistently, or currency and time zone conversions.

1. Agree with finance which figure is the reference and for which period, in writing.
2. Extract transaction-level records from the old database and from the system that replaced it.
3. Match them on a key both sides share, and list the records that exist on one side only.
4. Classify each difference by cause, using rules written down before looking at the totals.
5. Confirm a sample of each difference type against an independent source, such as bank records.
6. Present the reconciled figure with the list of differences and their causes, rather than an adjustment line.

We work on the CRM, Dataverse and data side of this problem, not on finance systems themselves; Solzet does not implement Dynamics 365 Finance, Business Central or other ERP. The steps for reconciling dashboard numbers to finance are covered in our post on dashboard numbers that do not match finance, and standing up reporting an auditor will accept is covered in trusted reporting that is audit-ready fast.

What goes in a reconstruction register?

One row for every reconstructed record, kept separately from the records themselves and never edited without a note. At minimum:

• Register reference and the identifier of the record it relates to, including any identifier from the original system.
• The date of the original event, as best established, and the date the reconstruction was made.
• Each value reconstructed, with the source it came from and where that source is stored.
• A confidence rating with defined meanings, for example confirmed by an independent third-party source, supported by internal records, or inferred from partial evidence.
• The values that could not be reconstructed and are left blank.
• Who reconstructed it and who reviewed it, by role.
• Any conflict between sources and how it was resolved.

Define the confidence levels before the work starts and have a second person review a sample of each level, so the ratings mean the same thing across the whole register.

How should reconstructed records be marked inside Dynamics 365 or another CRM?

So that nobody can mistake them for contemporaneous records, even years later and without the register to hand.

• Add columns for a reconstructed flag, the reconstruction date, the register reference and the confidence rating, and show them on the form and in views.
• Keep the event date in its own column. Dataverse lets migrations set the created on date through the overridden created on value, which is legitimate for migrating records that genuinely existed elsewhere at that date. Using it to make a record rebuilt today look as if it was created at the time of the event is exactly the kind of misleading record this post warns against, so let the system date show when the record was actually created.
• Attach or link the source evidence to the record where it is appropriate to store it there.
• Load the records with a dedicated, named migration identity, so audit history shows they arrived in a single dated load rather than looking like ordinary user activity.
• Exclude or flag reconstructed records in reports where it matters, so a trend line does not silently mix captured and rebuilt data.

How do you disclose the gap to an auditor?

In writing, before fieldwork finds it. A known, explained and controlled gap is far easier for an auditor to work with than a hidden one. The statement should set out the period and scope of the gap, how it happened, which sources were used and what they can and cannot prove, what could not be reconstructed, the reconstruction register itself, and the controls in place since with the date they began operating. Your compliance lead should own the statement; the technical team supplies the facts.

Where the gap is in Dynamics 365 audit history because auditing was switched off or scoped down, our guide to Dynamics 365 audit trails for compliance sets out what can be recovered for such a period and how to document it, so we do not repeat that here.

What controls stop the gap widening from today?

Capture that does not depend on someone remembering, in a system that keeps its own history. The specific controls depend on what went missing, but they usually include:

• Records created by the process itself, at the moment of the event, with system-generated identifiers and dates.
• Auditing turned on for the tables and columns that carry evidence, exported to long-term storage so capacity never becomes the reason it is switched off.
• Mandatory fields and reasons at the points an auditor will test, enforced on the server rather than only on the form.
• No delete rights for ordinary users on evidential records, and corrections recorded as new entries.
• A periodic check that auditing and the export are still running, with an owner.
• A decommissioning procedure that archives the old database and its documentation before any system is switched off, so the next reconstruction is a query rather than a project.

For reviewers who need to see how a record changed, the free Solzet Easy Audit PCF control presents existing Dataverse audit history as a readable side panel with a per-field timeline, filters and CSV export. It reads the history auditing has captured; it cannot show changes made while auditing was off, which is why the controls above come first.

If you are not sure what your environment captures today, where auditing is off, or which processes still happen outside the system, our Dynamics 365 health check and technical audit establishes that with evidence. Where the underlying system is being replaced, including by a custom-built CRM with an append-only change log designed around your retention rules, build the capture requirements into the specification from the start.

When should you stop reconstructing and simply declare the gap?

When the remaining records have no independent source, or when the effort of rebuilding them is out of proportion to what the auditor needs. Agree that threshold with the auditor early: they may be content with a reconstructed sample, a reconciled total and a clear statement of what is missing, rather than every record rebuilt. Past that point, further reconstruction increases the share of low-confidence, inferred records, which weakens the register rather than strengthening it.

How does Solzet help reconstruct records and prevent the gap recurring?

We recover and read data from legacy and decommissioned systems, restore and compare backups, reconcile sources at transaction level, build the reconstruction register and load reconstructed records into Dynamics 365, Dataverse or a custom-built CRM with clear labelling. We then implement the auditable capture that stops the gap recurring. We do not give legal, accounting or regulatory advice, and we do not implement finance or ERP systems; your compliance lead, auditor and advisers decide what is acceptable. Our senior consultants and full-stack developers deliver remotely from Yerevan, Armenia, directly or white-label for Microsoft partners.