Manage and troubleshoot
Audit and security
Keep commission evidence tamper-evident with append-only ledgers, SHA-256 hashes and segregation of duties, and run the integrity sweep over the ledgers.
updated: applies-to: 1.2.0.0
Commission records are financial evidence, so Bitta Commission keeps them tamper-evident and explainable. This page explains how the app protects evidence and separates duties, where auditors find the audit trail, and how you run the integrity sweep that checks the commission ledgers.
Before you start
- Auditors need the Bitta Commission Auditor permission set, which grants read access to configuration, organization, plans, sources, ledgers and evidence. Support staff use Bitta Commission Support, which reads setup and configuration. Neither set grants direct write access to commission tables. See Permission sets.
- Scoped pages also filter by the user's commission user scope. Give an auditor a Finance (all participants) scope if they must see every participant.
How evidence is protected
- Append-only ledgers. Source facts, credit, attainment, earning, tier consumption, eligibility, balance, settlement, accounting, aging and audit entries refuse every change or deletion after they are inserted. For the audit trail the error is BAA-AUDIT-APPEND-ONLY. A correction adds a new entry instead of editing the old one.
- SHA-256 hashes. Ledger rows carry an Entry Hash over their content. Plan versions carry a Definition Hash, each statement a Statement Hash that identifies the exact statement state and all frozen lines, and each settlement a Frozen Hash.
- Exact-version actions. Governed actions check the current version and hash of the record. A plan version, for example, is approved only while it is In Review and its Definition Hash still matches the one submitted for approval. An action on a stale copy is refused instead of overwriting newer work.
- Idempotency. Commands carry an idempotency key. Reusing a key for a different operation is refused with BAA-IDEM-CONFLICT.
Segregation of duties
The app refuses to let one person both request and approve the same change, unless that person is an administrator (see below):
| Situation | Refusal |
|---|---|
| The requester tries to approve their own plan, statement, settlement or posting request. | BAA-WFL-SELFAPPROVAL |
| An approval policy stage does not prohibit self-approval. Every stage must. | BAA-WFL-SELFAPPROVAL |
| A user who already decided on a request tries to decide on it again. | BAA-WFL-SEGREGATION |
| The requester approves their own correction request or manual correction. | BAA-COR-REQ-FOUR-EYES, BAA-COR-MANUAL-FOUR-EYES |
| The submitter approves a discretionary earning or a scorecard. | BAA-DISCRETIONARY-SOD, BAA-SCORECARD-SOD |
| The requester approves their own credit override. | BAA-CRD-OVERRIDE-SOD |
| The requester approves their own period reopen request. | BAA-RUN-REOPEN-SECOND-USER |
| The user who placed a hold that needs an independent release releases it. | BAA-HOLD-INDEPENDENT-RELEASE |
Administrator override. A user with the Bitta Commission Setup Administrator permission set or SUPER holds the administrator approval right. They may approve or reject their own plan, statement, settlement and posting requests and requests not assigned to them, and may pass the four-eyes checks in the table above (corrections, manual corrections, credit overrides, discretionary earnings, scorecards, independent hold releases and period reopens). The exception is an item that affects their own commission, that is, where a participant linked to the user is in its scope: an administrator is then refused like anyone else, and only a SUPER user may decide it. Every decision made under the right records its basis, "Administrator approval" or "Administrator approval (SUPER, own commission)", in the Administrator Approval field. Nobody, administrator or not, decides the same approval request twice (BAA-WFL-SEGREGATION), and every approval policy stage must still prohibit self approval. Limit who holds BAA Comm Setup Admin or SUPER, and review these decisions in your audit.
Plans therefore follow Validate, Submit, approval and Publish. Approval is by a second person, or by an administrator under the administrator approval right; the setup wizard takes its plan through these steps in that way. See Approval policies.
Review the audit trail
Every governed operation writes an audit entry with the area and action, the target record, version and hash, the before and after hashes, the reason, the acting user and any delegator, the time, session and client type, a permission context hash, the result or error code, a correlation ID and its own Entry Hash. An entry without complete operation, idempotency, signature, time, result and entry-hash evidence is refused (BAA-AUDIT-REQUIRED).
- On the role center, choose Audit Report, or search for Commission Audit Report. Filter by Area Code, Action Code, Target Type Code, Action At, the acting user or Result Code.
- Choose the layout: Audit report (print) or Audit report (Excel). Each row shows the target version with shortened before and after hashes, the user, the time and the result.
Each report run is recorded in Commission Export Evidence with its parameters, filters, security scope, row count and content hash. Release 1.2 adds more evidence pages: Commission Statement E-Mail Log lists every statement e-mail that was queued, skipped or failed, with the statement hash; Credit Memo Netting Entries shows how applied credit memos reduced commission; and Commission Release Log records every eligibility release run. For every report, see Commission reports. AI calls have their own append-only audit; see AI plan assistant.
Change log for commission setup
Setup records such as rates, credit rules and agreements are versioned with the plan, but you may also want a field-level history of who changed what. Enable Change Log on Commission Season Readiness switches on the standard Business Central change log for 30 commission setup tables: rate tables, columns and cells, rules and credit rules with their conditions, credit split and additive credit rules, plans, plan versions, components, measures, quotas and quota assignments, plan assignments, payment, return and recovery policies, aging, data quality and late data rules, customer agreements, value lists, commission costs, accounting policies and their settings, account mappings and participants. All fields are logged for inserts, changes and deletions. The action is shown only to users with the Setup Administrator permission set. Review the entries in the standard Change Log Entries page.
Recalculation approval on correction requests needs the separate Bitta Commission Recalculation Approver permission set; see Permission sets.
Run the integrity sweep
Commission Business Continuity records your backup and restore expectations and runs a read-only integrity sweep that recomputes entry hashes across the commission ledgers.
- Search for Commission Business Continuity. Review Backup Expectation, Recovery Point Objective (Hours), Recovery Time Objective (Hours) and Restore Test Interval (for example 3M), and choose Acknowledge Expectations.
- Set Integrity Sweep Sample Size (200 in a new setup), the number of most recent entries verified per ledger, and choose Run Integrity Sweep. Last Sweep At and Last Sweep Result show the outcome.
- Choose Sweep Log, select the sweep and choose Ledger Results. Each of the eleven ledgers (source facts, credits, attainment, earnings, tier consumption, eligibility, balances, settlements, accounting, audit and aging entries) shows its record count, the entries sampled, the mismatches and the most recent entry that failed. The result is BAA-SWEEP-OK, BAA-SWEEP-HASH-MISMATCH or BAA-SWEEP-EMPTY.
- After you restore a database or environment, choose Record Restore Test and enter the date and evidence reference. The app records the test and runs a sweep over the restored ledgers. Verify Encryption records whether data encryption is enabled.
WARNING
The sweep never repairs data. If it reports mismatches, do not try to fix ledger rows. Export the support diagnostics and contact Bitta Apps support.
User scopes
Permission sets decide what a user can do. Commission User Scopes decide whose records they can see: their own participant, a manager and descendants, or all participants. Saved scope history cannot be edited; add a new dated scope to change access. See Permission sets.
For the sanitized diagnostics package that support uses, see Job queue monitoring.
What's next
Fix the most common refusals: Troubleshooting.