Skip to content
Request Demo

Resubmission Diff Pack

Product Guide • Beginner • 2 min read

Audience
Lenders • Advisory Firms • Investment Committees
Last Reviewed
July 2026
Updated
Version 1.0

Executive Summary

The Resubmission Diff Pack answers the question every deal team asks at every resubmission cycle, what changed, and did the fixes hold, deterministically and at findings level. It compares a resubmitted model against the prior version already reviewed under an Independent Structural Model Review, classifying every finding as cleared, persisting, new, or reappeared, and surfacing structural deltas such as coverage or circularity changes. It attaches to an existing Review engagement at signature and is delivered on every resubmission cycle a deal goes through.

Key Takeaways

  • The Resubmission Diff Pack compares two versions of the same model at the findings level, classifying each finding as cleared, persisting, new, or reappeared.
  • It attaches to an existing Independent Structural Model Review engagement, typically as a rider agreed at the Review's signature, rather than being sold as a separate standalone engagement each time.
  • A finding that reappears after previously being marked cleared is flagged as the most prominent item in the deliverable.
  • It replaces manual version reconstruction, described as one of the most disliked tasks in a typical deal cycle.
  • Structural deltas beyond individual findings, including new or removed named structures, coverage changes, and circularity changes, are reported alongside the findings comparison.

Purpose

The Resubmission Diff Pack answers the question every deal team asks at every resubmission cycle: what changed, and did the fixes hold. It compares a resubmitted model against the version previously reviewed under an Independent Structural Model Review, at the Manifest and findings level, and reports the result deterministically, with the scope stated in writing.

Who It Is For

The customer base is the same deal teams served by the Independent Structural Model Review, at each point in the deal cycle where a model is resubmitted after remediation. Deals typically resubmit several times before reaching binding offer or close. Whoever bought the original Review is the buyer of each subsequent Diff Pack.

Problems Solved

  • A resubmitted model after remediation needs to be checked against the original findings without re-running a full structural audit from scratch.
  • Manually reconstructing what changed between two model versions is widely regarded as one of the most disliked tasks in a deal cycle.
  • Deal teams need to know not just what is new in a resubmitted model, but whether previously identified findings actually cleared, persisted, or reappeared.
  • A fix that regresses between resubmissions needs to be surfaced prominently, not buried inside a general findings list.
  • Structural changes beyond individual findings, such as new or removed named structures or a change in circularity, need to be reported alongside the findings comparison.

Workflow

The resubmitted model is run through the same structural rule pack used in the original Review. The resulting findings are compared against the findings set from the previously issued deliverable, matched by rule identity, location, and evidence, with reach-aware matching applied to clusters of related findings. Each finding is classified as cleared, persisting, new, or reappeared, and structural deltas, including coverage and circularity changes, are captured separately. The engagement typically runs as a rider attached to the original Review at signature, so it does not require a fresh sales cycle at each resubmission.

Outputs

The deliverable is the DIF report: an executive delta panel summarising cleared, persisting, new, and reappeared counts alongside the coverage delta and a one-line verdict per remediation class, followed by a cleared register documenting what the borrower fixed with supporting evidence, a persisting register ordered by severity, a new findings section, and a structural delta appendix. Reappeared findings are given the most prominent treatment in the document, since a fix that regressed is the single highest-value fact the deliverable can report.

Continue Reading

How OXXON tests thisRun a free structural check with FMAE

Frequently Asked Questions

What is the Resubmission Diff Pack?

A deterministic, findings-level comparison between a prior version of a model and a resubmitted version, reporting which findings cleared, persisted, are new, or reappeared.

Who uses the Resubmission Diff Pack?

The same deal teams served by the Independent Structural Model Review, at each point in a deal cycle where a borrower resubmits a revised model.

How is it different from re-running a full Independent Structural Model Review?

It compares the two versions directly rather than re-scoping and re-delivering a full review, and is priced and delivered faster because the underlying comparison work is largely automated.

What problem does it solve that manual review does not?

Manually reconstructing what changed between two model versions is time-consuming and error-prone; the Resubmission Diff Pack performs that comparison deterministically at the findings level.

What does reappeared mean in a Resubmission Diff Pack?

A finding previously marked as cleared that has come back in the resubmitted version, meaning a prior fix regressed. It is treated as the most significant class of finding in the deliverable.

How does the Resubmission Diff Pack get commissioned?

It typically attaches to an existing Independent Structural Model Review engagement as a rider agreed at signature, so it does not require a separate sales cycle each time a model is resubmitted.

Does the comparison look at formula text directly?

No. It compares model meaning at the Manifest and findings level rather than performing a cell-level text comparison of formulas.

What happens to a finding that only partially clears?

Where a cluster of related findings shrinks rather than fully clears, the deliverable states it as partially cleared rather than treating it as a simple cleared or persisting outcome.

Related Articles

What Is a Financial Model Audit?

A financial model audit is an independent, structured examination of an Excel based financial model to confirm that its mechanics, logic, and outputs are reliable enough to support a decision. It is not a check of whether the assumptions are optimistic or conservative. It is a check of whether the model actually calculates what its author believes it calculates. Every year, lenders extend debt, investment committees approve capital, and boards sign off on transactions using numbers that came out of a spreadsheet nobody outside the immediate deal team has independently verified. A financial model audit exists to close that gap before it becomes expensive.

Manual vs Automated Financial Model Audit

Financial model audit can be performed manually, by a human reviewer applying professional judgement and a defined process, or through automated, deterministic software that systematically tests every formula against a fixed rule set. This page compares the two approaches on coverage, consistency, turnaround, and appropriate use case, consistent with the broader distinction described on the AI Financial Model Audit pillar page.

What Is a Project Finance Model Audit?

A project finance model audit is a financial model audit applied to the specific class of model used to finance infrastructure, energy, and long dated capital projects: debt sculpted, multi decade, cash flow driven structures with mechanics that do not appear in a typical corporate model. It is frequently a formal condition of financial close, not an optional check, and lender requirements for it exist almost entirely inside non public bank credit policy rather than any single consolidated public source. This page defines what makes project finance models structurally distinct, why lenders require independent verification of them specifically, and what the audit process looks like in this context.

Request Demo