Entity certification workflow

Certification statuses

Every entity-period combination tracks a certification status. The status advances through a fixed sequence. It cannot skip steps or move backward except through an explicit rejection.

1. NOT_STARTED: the default state when a period is first opened. No close tasks have been initiated for this entity.
2. IN_PROGRESS: at least one close task has been started or completed. The preparer is actively working through the checklist.
3. READY_FOR_REVIEW: the preparer has completed all required tasks and submitted the entity for review. At this point, the preparer's work is frozen, and no further edits to reconciliations or journal entries are permitted without a rejection.
4. UNDER_REVIEW: a reviewer has opened the entity and is actively examining the work. The reviewer sees a consolidated view of all reconciliations, journal entries, and supporting documentation.
5. CERTIFIED: the final approver (typically the controller or VP of accounting) has signed off with attestation. The entity's books for this period are considered final.
6. LOCKED: the period has been locked by an administrator after all entities are certified. No changes are possible without an explicit unlock. See period management for details on locking.

Multi-level review chain

Arvexi supports up to four levels of review before certification. Each level is configured per entity or entity group, and the chain is enforced sequentially.

• Level 1: Preparer: the staff accountant who completes the close tasks, reconciliations, and journal entries. Submits work for review when all required items are done.
• Level 2: Reviewer: typically a senior accountant. Reviews reconciliation quality, checks variance explanations, and validates journal entries against supporting documents.
• Level 3: Approver: typically a manager or assistant controller. Reviews the overall entity close package, checks completeness, and validates that review notes from Level 2 have been addressed.
• Level 4: Certifier: the controller or VP of accounting. Performs the final certification with attestation. This is the sign-off that appears on the audit trail.

Not every entity needs all four levels. A small subsidiary might use a two-level chain (preparer and certifier), while a complex operating entity might require all four. Configure the chain in Settings > Entities > Certification Chain.

The certification checklist

Before a preparer can submit an entity for review, every item on the certification checklist must be satisfied. The checklist is auto-generated based on the close task templates assigned to that entity. Requirements include:

• All RECONCILIATION tasks marked complete with zero unexplained variance.
• All JOURNAL_ENTRY tasks posted and approved.
• All REVIEW tasks signed off by the designated reviewer.
• All CORTEX_SWEEP tasks completed with no unresolved RED findings.
• All BASIC and APPROVAL tasks marked complete.
• No open comments or unresolved flags on any task.

If any checklist item is incomplete, the Submit for Review button is disabled. The preparer sees a clear list of outstanding items with links to each one.

Sign-off with attestation

At the final certification step, the certifier sees an attestation statement that must be explicitly acknowledged before the entity can be certified. The attestation reads:

I certify that the financial records for [Entity Name] for the period ending [Period End Date] have been prepared in accordance with company accounting policies, are materially accurate, and are supported by appropriate documentation.

The certifier must check the attestation box and click Certify. Arvexi records the certifier's user ID, timestamp, IP address, and the exact attestation text at the time of sign-off. This record is immutable and cannot be edited or deleted after the fact.

What the audit trail captures

• Every status transition (NOT_STARTED to IN_PROGRESS, etc.) with timestamp and user.
• Every review action (approved, rejected) with the reviewer's comments.
• The final attestation text, certifier identity, and timestamp.
• Any subsequent unlock or re-open events, with the administrator who authorized the action and the stated reason.

Rejection with reason

At any review level, the reviewer can reject the entity back to the previous level. A rejection requires a reason, and the reviewer must describe what needs to be corrected.

• Targeted rejection: the reviewer can flag specific tasks or reconciliations that need rework. The preparer sees exactly which items require attention.
• Status rollback: on rejection, the entity status moves back to IN_PROGRESS. The preparer regains edit access to reconciliations and journal entries.
• Rejection history: all rejections are logged with the reason, the reviewer who rejected, and the flagged items. This history persists even after the issue is resolved and the entity is re-submitted.
• Notification: the preparer receives an in-app notification and email when their entity is rejected. The notification includes the rejection reason and links to the flagged items.

Segregation of duties enforcement

Arvexi enforces segregation of duties (SOD) at every level of the certification chain. The rules are non-negotiable:

• A user cannot review their own work. If a staff accountant prepares the close tasks, they cannot also serve as the Level 2 reviewer for the same entity-period.
• A user cannot appear at two different levels of the same certification chain. A manager who acts as the Level 3 approver cannot also be the Level 4 certifier.
• The system blocks the action at runtime. If a user attempts to approve at a level where they already participated, the approval button is disabled with a clear SOD violation message.
• SOD violations are logged. Even a blocked attempt is recorded in the audit trail for compliance teams to review.

SOD enforcement can be configured to follow either a strict model (the above rules with no exceptions) or an override model where a system administrator can grant a one-time exception with a documented reason. The override and its justification are permanently recorded.

Period lock after certification

Once every entity in a period reaches CERTIFIED status, the period is eligible for locking. Locking is a separate administrative action. Certification alone does not automatically lock the period.

When a period is locked:

• All reconciliations become read-only. No balances, matching, or variance explanations can be modified.
• Journal entries cannot be posted, edited, or reversed for that period.
• Close tasks cannot be reopened or modified.
• The certification chain cannot be reset without first unlocking the period.

For details on the lock/unlock process and period lifecycle, see period management and locking.

Configuration checklist

Before your first certified close, confirm these settings:

1. Define review chains: for each entity or entity group, configure the number of review levels (2-4) and assign the roles for each level.
2. Map users to roles: ensure every entity has at least one user assigned at each level of its review chain. Arvexi warns you during period opening if any entity has an incomplete chain.
3. Set SOD policy: choose strict or override mode in Settings > Compliance > Segregation of Duties.
4. Customize attestation text: the default attestation text can be edited in Settings > Close > Attestation. Some organizations add references to specific policies or regulatory requirements.
5. Test the flow: run through a full certification cycle in a test period. Submit, review, reject, re-submit, and certify to confirm that the chain works as expected.