BreezyCorp Handbook

Appearance

Validation rule keeps failing across iterations ​

You fixed what looked like the cause of an ERROR-severity rule, re-ran validation, and the same rule failed again. Multiple iterations have not cleared it.

What this means ​

The error is sticky for one of three reasons:

  1. The fix didn't actually change the inputs the rule consults. Rules consult specific elements; if you fixed a different element, the rule still sees the bad data.
  2. The underlying data really is wrong. The source financial statement has an inconsistency that you can only fix at the source.
  3. The rule expression is wrong. Rare, but possible — the constitution-versioned rules are precise but not infallible.

Diagnose ​

Confirm which elements the rule consults ​

sql
SELECT rule_id, message, related_elements
  FROM xbrl_validation_results
  WHERE xbrl_filing_id = '<filingId>' AND rule_id = '<offending_rule_id>'
  ORDER BY run_at DESC LIMIT 1;

related_elements is the canonical list. Every element listed there is in scope for the rule.

Confirm the actual values ​

sql
SELECT li.label, tm.element_id, li.value_current, li.value_prior
  FROM xbrl_tag_mappings tm
  JOIN xbrl_line_items li ON li.id = tm.line_item_id
  WHERE tm.xbrl_filing_id = '<filingId>'
    AND tm.element_id = ANY(<related_elements>);

Sit with the rule's message and the actual values side by side. Compute the rule's arithmetic by hand. Does the data really violate the rule, or is your expectation wrong?

Fix paths ​

Case 1 — wrong line item fix ​

Your previous edit landed on a different line item. Revisit; find the right one by relatedElements; fix and re-validate.

Case 2 — data is wrong at source ​

The source DOCX has a real inconsistency. Common patterns:

  • Equity closing balance does not equal Equity opening + PAT + Movements. Likely a missing share-capital movement in the SOCE.
  • Cash flow opening + Operating + Investing + Financing ≠ Cash flow closing. Likely a missing accrual movement.

Fix at the source statement (the client may need to re-issue) or — if confident — edit the line-item value in the Mappings tab. Manual edits are audited.

Case 3 — escalate ​

If after 3 iterations the rule still fails and you're certain the data is correct, escalate to Senior Accountant. Possible outcomes:

  • The rule is misinterpreting the data → file a constitution-level issue.
  • The rule has an ACRA-side ambiguity → document the rationale on the filing log; consider whether to file regardless (warnings do not block; some clients have filed despite specific WARNING rows).
  • A constitution-versioned rule update is required.

Why we don't allow overrides ​

The export gate has no override path. The whole point of the gate is that no XBRL output leaves the system with an unresolved error. If the rule is genuinely wrong, the constitution-level fix is the right path; one-off overrides per filing would erode the gate's value.

Internal use only — BreezyCorp