BreezyCorp Handbook

Appearance

ACRA rejected the filing after submission ​

You marked the filing as FILED with an ACRA reference, but ACRA subsequently rejected it. Sometimes this comes through email, sometimes through the BizFinx Preparation Tool, sometimes through a follow-up call.

What this means ​

The platform's gate let the file through (validation passed, every mapping confirmed) but ACRA's submission-side validation caught an issue. The filing is now FILED in the platform but invalid at the regulator.

Recovery path ​

The FSM allows EXPORTED → MAPPING_IN_PROGRESS (back-out before filing). It does not directly allow FILED → MAPPING_IN_PROGRESS. Two options:

Option A — corrective re-filing in a new XbrlFiling row ​

The cleanest path for audit traceability:

  1. Leave the rejected filing as-is in FILED state with a note in the activity log explaining the ACRA rejection.
  2. Create a new XbrlFiling for the same client + period (the taxonomyVersion should match the prior pin unless ACRA has re-published the taxonomy in the meantime).
  3. Document the linkage: in the new filing's notes, reference the rejected filing's id.
  4. Fix the issue (mapping or data); re-run validation; re-export; re-submit; mark filed.

Option B — revert the existing filing (requires manual fix) ​

If the rejection is fast enough that re-submission is in the same ACRA workflow:

  1. The status machine has no FILED → MAPPING_IN_PROGRESS transition out-of-the-box. A PLATFORM_ADMIN can revert via a direct DB update (or a future support endpoint).
  2. The reverted filing returns to MAPPING_IN_PROGRESS; fix; re-validate; re-export; re-submit.
  3. Document the revert on the filing log with the ACRA rejection reason.

CAUTION

Option B is a manual-intervention path. Prefer Option A for clean audit trails. Use Option B only when re-creating the filing would lose meaningful audit history.

Common ACRA rejection reasons ​

  • A mandatory element required for the entity type was not provided (the platform's validation may have warned but not erred).
  • A monetary value precision issue (Decimal(20,2) is enforced by the platform; ACRA occasionally rejects on precision edge cases).
  • A taxonomy-version mismatch (e.g. ACRA released a new mandatory version effective for the period; the platform's pinned version is older).

Fix forward ​

If the rejection points at a constitution-level gap (a WARNING rule that should be ERROR, or a missing rule entirely):

  1. File a constitution-level issue.
  2. The fix lands in packages/xbrl/constitution/validation_rules_<version>.json.
  3. Re-run validation across in-flight filings.

Internal use only — BreezyCorp