Financial Controls
Which controls we operate, who owns each, when it was last tested and what we are doing about the ones that failed. A different shape from an audit log, which records changes rather than assurance.
Where to find it
- Module: Accounting
- Group: Close & Compliance
- Section: Financial Controls
- Screen: Financial Controls
Address in the console: /accounting/financial-controls
List · 15 columns · 22 fields on its form · 2 of them required · 1 action
What the list shows
These are the columns of the list, in the order they are drawn. Any of them can be sorted on, filtered on, hidden, or exported.
| Column | Kind | Field name |
|---|---|---|
| Control | Code | control_no |
| Name | Text | name |
| Process | Status | process |
| Type | Status | control_type |
| Nature | Status | nature |
| Key | Yes or no | is_key |
| Owner | Text | owner_name |
| Performed by | Text | performer_name |
| Reviewed by | Text | reviewer_name |
| Self-reviewed | Yes or no | performer_reviews_own_work |
| Effectiveness | Status | effectiveness |
| Last tested | Date | last_test_date |
| Days | Number | days_to_test |
| Overdue | Yes or no | test_overdue |
| Deficiencies | Number | open_deficiencies |
The form
What is asked for when a record is created here. Required fields are marked; a choice drawn from a configuration list is one an administrator can extend without a release.
| Field | Type | Choices | Notes |
|---|---|---|---|
| Name required | Text | ||
| Framework | Choice | Looked up from existing records | |
| Framework reference | Text | ||
| Process required | Choice | Configuration list | |
| Type | Choice | Configuration list | A framework made entirely of detective controls finds everything and prevents nothing. |
| Nature | Choice | manual, automated, it_dependent, hybrid | Automated controls are tested once and rely on change management; manual ones on a sample every period. |
| Frequency | Choice | continuous, daily, weekly, monthly, quarterly, annual, event_driven, ad_hoc | |
| Key control | Yes or no | Its failure could cause a material misstatement. Marking everything key is how a framework becomes untestable. | |
| Risk addressed | Long text | ||
| Assertion | Text | Existence, completeness, valuation, rights, presentation. | |
| Owner | Choice | Looked up from existing records | |
| Performed by | Choice | Looked up from existing records | |
| Reviewed by | Choice | Looked up from existing records | |
| Owner role | Text | ||
| Module | Text | ||
| Screen | Text | ||
| Enforced in code by | Text | Where the product itself refuses the thing, a test becomes "does that check still exist" rather than a sample of forty. | |
| Design | Long text | ||
| How it operates | Long text | ||
| Evidence required | Long text | ||
| Next test due | Date | ||
| Notes | Long text |
What you can do here
Record a test primary
A control tested by the person who operates it is not tested — this refuses unless you deliberately record it as a self-assessment.
Asks for: Test type Period Population Sample size Sample method Exceptions found Conclusion Evidence I operate this control — record it as a self-assessment
The rules that apply here
Everything on this screen obeys the platform rules rather than rules of its own. The ones worth knowing before you use it:
- Narrowing a list — search, conditions, sort, totals, export and saved views.
- What may be changed — the five grounds a record may not be edited on.
- Companies and business units — what the switcher above this list is doing to it.
- Creating a record — required fields, where choices come from, and how the number is allocated.
- Importing a spreadsheet — this screen accepts one, and it runs through the same rules as typing.