Practice
Completing an engagement
Complete is a professional statement, so it is derived rather than asserted. There is no progress bar filling up as boxes get ticked: each requirement is a question about what the engagement actually holds, answered from stored state every time it is asked.
The requirements
| Requirement | Satisfied when |
|---|---|
| A ledger has been imported | At least one general-ledger dataset exists |
| The ledger has been validated | At least one validation run exists |
| Every statement has been reconciled | There are as many reconciliations as statements |
| Every control account has been reconciled | A configured control scope has been run |
| Every subledger has been reconciled | There are as many subledger runs as subledgers |
| Every finding has a disposition | No finding is still open or under investigation |
| A working paper has been produced | The working-paper index is not empty |
| A reviewer is named | Advisory. A local label, not an identity |
| Insufficient-data results considered | Advisory. Each one is a check the export could not answer |
A requirement that does not apply. A bank reconciliation for an engagement with no statement. Is not applicable, and says which fact made it so. That is not the same as met, and the screen does not pretend it is.
Four states, and the middle one matters
- Met, the engagement's state satisfies it.
- Unmet. It does not, and completion is blocked.
- Not applicable. Nothing to do, and the reason is shown.
- Overridden. It is still unmet, and a named person recorded why that is acceptable.
An override is not the warning going away
Completing
The button is available only when nothing required is unmet. Every blocking requirement is either satisfied or overridden. Completing records who did it and when, marks the engagement completed, and writes an entry to the review trail naming how many requirements were met and how many were overridden.
Nothing is ever marked complete silently, and nothing is completed as a side effect of something else.
The working-paper index
Beside the requirements is the index of everything VLDTION produced for the engagement: each document with its type, when it was produced, by whom, the datasets it rests on, the runs it quotes and the methodology versions in force.
| Traceability | Meaning |
|---|---|
| Traceable | Every dataset the paper rests on is still in the workspace, unchanged |
| Data changed | A dataset was re-imported and its fingerprint moved. The paper still describes what it was made from. It is not re-pointed at the new data |
| Data absent | The data is no longer in the workspace. The paper still records what it was |
That middle row is the important one. A corrected export is an ordinary event, and a paper already in the file must not silently start claiming to describe data that arrived after it.