Reports, audit evidence and security controls

Open the POS audit register

Follow this guide to review the most recent 200 tenant events. The guide then takes you through the correct route, the checks to complete before making changes, the workflow in order, and the evidence to review afterwards.

Audience: Managers, finance staff, auditors and security reviewersPermission: View reports or View auditModule v1.0.0 · code-inspected

Jump to steps

Where to goEnterprise POS → Reports / Audit

What you’ll accomplish

Review the most recent 200 tenant events. This section explains report filters, exclusions, audit chaining and the module’s principal security controls.

Follow these steps

Go to Enterprise POS → Reports / Audit and open the workflow that matches “Open the POS audit register”. Confirm the page or record context before making a change.
Go to Reports and choose a date range.
Run the summary and review sales, collected amounts, channel breakdown and top products.
Go to Audit and review recent tenant events.
Use correlation IDs to connect order, payment, stock, return and integration events.
Escalate anomalies without rewriting records.

Fields and options to review

Guide focus: Review the most recent 200 tenant events.
From/to dates
Location timezone
Sales and collected totals
Sales by channel
Top 20 products
Audit event type, object, actor, reason, summary, correlation and chain hash

Rules the system enforces

Reports default to the current calendar month.
Reversed from/to inputs are swapped.
Cancelled, void, refunded and returned orders are excluded.
Top products are limited to 20.
Audit UI displays the most recent 200 events.
Each audit event HMAC includes the previous event hash and tenant context.

How to confirm it worked

The specific outcome described by this guide is visible and remains tenant-scoped.
Report totals match eligible committed orders.
Audit events form an ordered tenant chain.
Correlated operations can be reviewed without database edits.

Safety checks and troubleshooting

Treat reports as operational summaries, not a substitute for formal accounting.
Do not alter audit rows.
Protect settings keys, public tokens, API secrets and webhook secrets.

Stay within the supported module flow

Use the supplied UI, host module lifecycle and documented endpoints. Do not bypass tenant filters, permissions, CSRF, idempotency, rate limits, audit evidence or transaction checks. A stored table or field does not imply that version 1.0.0 exposes a management screen for it.

Was this guide useful?Your response is stored only in this browser.