Audit and security

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:

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

Plans therefore follow Validate, Submit, approval by a second person and Publish. 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).

1. 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.

2. 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. For every report, see Commission reports. AI calls have their own append-only audit; see AI plan assistant.

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.

1. 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.
2. 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.

3. 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.

4. 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.

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.