Corporate governance
ERP governance, permissions and approval workflows
Put your authority rules around the ERP work people do every day. Connect role permissions, approval routes, validation and audit records so your team can explain who requested a decision, who reviewed it and what evidence supported it.
These approval workflows are often called maker-checker controls: one person enters or requests a transaction, and a different person approves it. VisionONE routes transactions to designated approvers and applies approval limits based on the authority assigned to each approver. For bank reconciliation, goods receipt checks, statutory reminders and related controls, see internal controls in VisionONE.
Roles & access
Define who can see, create, review and approve records, with permissions aligned to company, branch and document responsibilities.
Multi-level approvals
Route requests through the agreed authority levels, using the amount, department and document context your team needs.
Separate responsibilities
Keep sensitive requests and approval decisions with different people, including payment requests and supplier changes.
Validation & exceptions
Review the information required before approval. Give incomplete records and policy exceptions a documented path for resolution.
Audit history & evidence
Keep the people, decisions and supporting records behind a transaction available for review. Confirm the logged events and reporting scope.
Task ownership & follow-up
Assign the next action and its owner alongside the business record. Review pending decisions and the supported follow-up process.
Governance controls connected to VisionONE ERP
Discuss your approval workflowOn this page
Part of VisionONE ERP
Multi-level approvals and task ownership
From the request
to a decision you can explain.
Follow one fictional request through ownership, policy checks, two separate reviews and the supporting history. Keep tasks and approval decisions connected to the same ERP record.
Stage 1 of 4 · Request
Start with the request and its supporting record.
REQUESTER-A raises the fictional purchase request GOV-DEMO-011 for KES 120,000. The record identifies COMPANY-DEMO-A, the Operations department and quote Q-DEMO-011. The requester owns the request; the illustration gives approval responsibility to other people.
Illustrative record
- Request
- GOV-DEMO-011
- Requester
- REQUESTER-A
- Department
- Operations
- Requested amount
- KES 120,000
Stage 2 of 4 · Check
Check the context before routing the decision.
The example policy requires a department review for this request and an additional finance approval above KES 100,000. KES 120,000 exceeds that fictional limit. Review the supporting quote and assigned roles before sending it to the two separate reviewers.
Illustrative record
- Supporting record
- Q-DEMO-011
- Example finance trigger
- Above KES 100,000
- Required reviews
- Department and finance
- Self-approval
- Outside example policy
Stage 3 of 4 · Approve
Keep each reviewer’s decision distinct.
REVIEWER-B completes the department review. APPROVER-C gives the final finance approval after checking the request and supporting records. The example records both decisions; neither is performed by REQUESTER-A.
Illustrative record
- Department review
- REVIEWER-B
- Finance approval
- APPROVER-C
- Illustrative outcome
- Approved
- Requested amount
- KES 120,000
Stage 4 of 4 · Record
Read the decision with the people and records behind it.
Keep the original request, supporting quote and approval history together. This illustration finishes with an approved purchase request. It does not create a purchase order, release a supplier payment or demonstrate a legally binding electronic signature.
Illustrative record
- Request
- GOV-DEMO-011
- Supporting record
- Q-DEMO-011
- Recorded reviewers
- Two separate people
- Payment release
- Not modelled
The roles and KES 100,000 trigger are invented company-policy examples, not legal thresholds or a VisionONE configuration screenshot. Confirm the actual supported route, task statuses, reminders and escalation behaviour using your own approval matrix.
Roles, approval records and audit history
Know who acted,
and what supported the decision.
ERP approval workflow software in Kenya should help teams connect the authority matrix with the request and its recorded reviews. Use the same source record to examine roles, decisions and evidence.
See the responsibilities before the decision.
In the fictional matrix, REQUESTER-A raises the request, REVIEWER-B handles the department review and APPROVER-C gives final finance approval. They operate within COMPANY-DEMO-A; this illustration grants no access to another company.
- Independent reviewers
- 2 peopleRequester and reviewers are separate
| Role | Review | Final |
|---|---|---|
| RequesterREQUESTER-A · raises request | No | No |
| Department reviewerREVIEWER-B | Yes | No |
| Finance approverAPPROVER-C | Yes | Yes |
This is a fictional authority matrix for one request. It does not imply that every role can view all records or approve all amounts; company, department and document permissions need their own setup.
Read each review, not just the final status.
The KES 120,000 request needs two reviews under the example policy. The department review and final finance approval are recorded separately. Approval of the request does not establish that an order or payment has been created.
- Approved request amount
- KES 120,000Two completed reviews · no payment modelled
| Review step | Outcome |
|---|---|
| Department reviewREVIEWER-B · supporting quote checked | Completed |
| Finance approvalAPPROVER-C · final decision | Approved |
| Payment releaseSeparate financial workflow | Not modelled |
Keep rejection, return-for-information and reassignment outcomes available in the actual workflow review. Confirm escalation and alternate-approver behaviour before enabling a route.
Follow the source and the recorded decisions.
The fictional sequence records a request at 09:10, department review at 09:25 and finance approval at 09:40 on an example business day. The quote reference stays with the request. Use a real audit-log sample to confirm which events and fields are captured.
- Source record
- GOV-DEMO-011Supporting quote: Q-DEMO-011
| Event | Time | Actor |
|---|---|---|
| Request raised | 09:10 | REQUESTER-A |
| Department review | 09:25 | REVIEWER-B |
| Finance approval | 09:40 | APPROVER-C |
The example demonstrates a decision trail, not immutable logging or a retention guarantee. Ask to review logged changes, user and time fields, access restrictions and available exports in the current version.
All views are educational examples, not customer records or a product role matrix. Ask to see the current permission setup, a demonstrated approval route and an anonymised audit-log sample during your demo.
Roles and company-level access
The right person,
with the right record access.
Define the ERP governance and access permissions your team needs to work. Review who may view sensitive records, create a request, change master data and approve a decision within each company or branch.
- Map visibility and actions to the company, branch and document responsibility.
- Review the combination of roles, so request and approval duties remain appropriately separated.
- Recheck access when someone joins, moves roles, leaves or receives temporary authority.
Access controls and deployment security need their own evidence.
Request the current security factsheet for your deployment. Confirm supported identity options, hosting and backup responsibilities separately from transaction permissions; the role matrix does not establish those controls by itself.
Review the company, branch and document scope for each user. Include sensitive HR, payroll and finance records in the access review.
Separate requesting, reviewing and approving duties for the records that need independent checks.
Keep permission changes and review decisions with the evidence your team needs. Confirm the actual logged events and reporting access.
Use a demonstrated permission model and documented deployment facts when agreeing the scope.
Validation and exception handling
Keep the evidence,
the question and the next action together.
An approval is useful when the reviewer has enough context to make it. Bring incomplete records, unresolved differences and sensitive changes into a clear follow-up process with an assigned owner.
Keep supporting documents with the request
Identify the quote, invoice, contract or change evidence the reviewer needs. Make the record accessible to the responsible people within the agreed permissions.
Return incomplete records with an owner
Record what needs correction, who will resolve it and the next review step. Confirm the task status, reminders and escalation supported by the actual workflow.
Review the final decision and its history
Read the outcome alongside the requester, reviewers and supporting records. Agree the history fields, reporting access and retention responsibilities your review requires.
Segregation of duties and practical controls
Make the policy
worth testing.
Turn internal control requirements into specific records, roles and test cases. Confirm the supported behaviour before the rules are used for live purchasing, payments or sensitive changes.
Authority levels and limits
Agree approval responsibilities by amount, department and document type. Test the boundary cases rather than relying only on a routine request.
Segregation of duties
Review requester, master-data editor, approver and payment responsibilities. Test prohibited role combinations and self-approval for the sensitive workflows in scope.
Alternate review and escalation
Name the owner of a pending decision and agree absence cover. Confirm supported delegation, reminders, escalation and approval expiry behaviour in the demo.
Required fields and supporting records
Specify which records and checks are needed before a decision can proceed. Review missing information, exceptions and permitted overrides with their approval path.
Audit evidence and access
Review captured actions, user and time information, before/after values where supported, and available reporting. Agree who may view or export the history.
Periodic permission review
Review active users, companies, branches and role combinations with a named owner. Record approved changes and re-test the affected access and approval routes.
Connected governance and ERP records
Keep the policy,
the transaction and its evidence in view.
Choose the purchase, budget and document workflows around the decisions your team needs to review.
Start with your operational controls. This page focuses on role permissions, approval routes, task ownership and audit evidence inside the ERP. Agree the supported workflows and the records your organisation needs to demonstrate its decisions.
Governance setup and testing
Roles, routes
and rollout.
Agree the authority matrix, source records and control owners first. Use a demonstrated workflow and its decision history to review the setup before wider use.
Prepare the authority and role matrix
Bring companies, branches, departments, users, document types and approval limits. Include the sensitive role combinations and source evidence your controls must address.
Configure and demonstrate the routes
Review permissions and required fields, then test a routine approval, a rejected or returned request, a self-approval attempt and an absent reviewer scenario.
Verify history and review responsibilities
Check the resulting records and audit evidence with the control owner. Agree access review, training, retention, support and change responsibilities before wider use.
Questions, answered
Before your
governance demo.
Bring the approval rules you use today and one sensitive decision you need to explain. Confirm the roles, workflow limits and evidence your team needs.
Does VisionONE support maker-checker approvals?
Yes. VisionONE routes transactions to designated approvers and applies approval limits based on the authority assigned to each approver. This is commonly called maker-checker: the person who enters a request is not the person who approves it. Ask to see your authority matrix, including a self-approval attempt, in the demo.
Can the requester and approver be separate people?
Yes. VisionONE’s suite describes segregation of duties for sensitive transactions, including payment requests and supplier bank-detail changes. Agree the relevant roles and test the actual route with an attempted self-approval before go-live.
Can approval limits differ by department?
VisionONE’s published suite describes multi-level approvals by amount, department or document type. Bring your authority matrix and test the required limits, boundary cases and company or branch context during configuration.
Which changes are logged?
VisionONE describes audit records and transaction history. Confirm the exact events, fields and document types logged in the current version using an anonymised sample. Review who can access the history, available exports and the agreed retention responsibilities.
How are permissions reviewed?
Review users and their assigned roles against the approved company, branch and document responsibilities. Assign a control owner, check sensitive role combinations and record agreed changes. Test the affected visibility, editing and approval actions after a role change.
How are tasks connected to approval decisions?
Keep the next action, owner and supporting record linked to the business request. Confirm the actual task types, statuses, reminders and escalation supported in the demo. A task assignment and an approval decision are related records with different responsibilities.
Can reminders and escalations be configured?
Confirm the supported reminder, alternate-reviewer and escalation behaviour for your actual workflow and product version. Agree who owns overdue decisions and what happens during an absence. The example does not assume automatic reminders or every escalation option.
What security information should we request?
Request the current security factsheet for your deployment and documented identity, hosting and backup responsibilities. Confirm any required MFA or SSO availability separately. Role-based transaction permissions do not by themselves establish hosting controls or certifications.
What should we bring to a governance demo?
Bring your authority matrix, user-role list and one request with supporting documents. Include a self-approval concern, sensitive master-data change or absent reviewer case, and the decision history your team needs to retrieve.
See it with your records
Bring one request.
Follow every review and decision.
Review the source record, authority matrix and supporting evidence. Include one exception so the demo covers the responsibilities behind a completed approval.
A focused demo around your approval work, with no obligation.