Validation

Before building your financial model, the application runs a comprehensive set of structural and completeness checks on your specification. Validation catches configuration problems early, preventing build failures and ensuring the generated Excel model is internally consistent.

Think of validation as a pre-flight checklist. Just as a pilot verifies instruments, fuel, and controls before takeoff, validation verifies that your model specification is complete and coherent before the build pipeline begins.

Severity Levels

Each validation finding is classified into one of three severity levels:

Errors

Errors represent problems that must be fixed before building. The build pipeline will not start if any errors are present. Errors indicate structural issues that would produce a broken or incorrect Excel model.

Examples of errors:

• A required Master Account prefix is missing.
• An account references a parent that does not exist.
• Duplicate account codes are defined.
• No projection periods are configured.

Warnings

Warnings indicate potential issues that do not block the build but may result in unexpected output. The model can be generated with warnings present, but you should review them to decide whether they require attention.

Examples of warnings:

• An account is defined but not referenced by any parent (orphan account).
• A Key Assumptions link is enabled but no eligible accounts exist.
• A chart references an account code that has no data.
• The perpetuity growth rate is close to the discount rate.

Info

Informational findings provide context and suggestions without indicating any problem. They help you understand the model's configuration and may suggest improvements.

Examples of info findings:

• The model contains a large number of accounts (performance note).
• Certain optional features are not configured.
• Summary statistics about the specification.

Common Validation Errors and How to Resolve Them

Missing Master Accounts

Message: "Income Statement prefix is not defined" (or similar for other statements).

Cause: One or more Master Account prefixes have not been set.

Fix: Navigate to the Master Accounts section and assign a numeric prefix to each financial statement category. All five prefixes (Income Statement, Assets, Liabilities, Cash Flow Statement, Free Cash Flow) should be defined.

Orphan Account References

Message: "Account 3150 references parent 3100, which does not exist."

Cause: An account's parent code points to an account that is not defined in the chart of accounts.

Fix: Either create the missing parent account or update the child account's parent reference to point to an existing account.

Duplicate Account Codes

Message: "Account code 3100 is used by multiple accounts."

Cause: Two or more accounts share the same code. Account codes must be unique.

Fix: Change one of the duplicate codes to a unique value. Review your numbering scheme to prevent future collisions.

Missing Periods

Message: "No projection periods are defined."

Cause: The model has no time periods configured, so there is nothing to project.

Fix: Navigate to the Periods section and define at least one projection period with start and end dates.

Circular References

Message: "Circular dependency detected involving accounts 3100, 3200, 3300."

Cause: A chain of account references forms a loop (A references B, B references C, C references A).

Fix: Review the parent-child relationships and formula references for the flagged accounts. Break the cycle by changing one account's reference.

Invalid FCF or EBITDA Account Code

Message: "FCF Account Code 5100 does not match any existing account."

Cause: The account code specified in Master Accounts for FCF or EBITDA does not correspond to a defined account.

Fix: Either create the referenced account or update the Master Accounts setting to point to an existing account code.

The Validation View

The validation interface presents findings in an organized layout:

Summary Cards

At the top, summary cards show the count of errors, warnings, and info items. Color coding (red for errors, amber for warnings, blue for info) provides an immediate sense of the specification's health.

Issue Cards

Below the summary, each finding is displayed as a clickable card. Cards include:

• Severity icon — error, warning, or info.
• Message — a clear description of the finding.
• Affected account or section — identifies where the issue originates.

Clicking an issue card navigates you directly to the affected section or account in the editor, so you can fix the problem without searching for it manually.

When Validation Runs

Validation runs automatically:

• Before every build — the build endpoint runs the exact same validation routine as the Validate button (one shared gate, so the two can never disagree). If errors are found, the build is refused and the findings are returned.
• On demand — you can trigger validation at any time from the Validation section to check your specification's health without starting a build.
• On open and import — opening an Excel specification or importing YAML also runs the gate and reports the result, so you see a file's health the moment it loads.

Validation does not modify your specification. It is a read-only check that reports findings for your review.

Best Practices

• Validate frequently during model development, not just before building. Catching issues early is faster than debugging them after creating many accounts.
• Address errors first, then review warnings. Errors block the build; warnings are advisory.
• Do not ignore warnings. While they do not prevent building, they often indicate real problems that will produce confusing output.
• Use the click-to-navigate feature on issue cards to jump directly to problems rather than scrolling through the specification manually.