Audit Trail, Offline Sync & Reconciliation Strategies

The POS domain maintains a comprehensive, immutable audit trail for every shift, transaction, and cash movement. Corrections are achieved through compensating documents rather than record mutation, and offline operations are reconciled through strict replay policies.

---

1. POS Audit Trail

Every mutation within the POS context is recorded with immutable context. The audit trail supports cash accountability, fraud prevention, regulatory compliance, and operational investigation.

Audit Attributes

Attribute	Purpose
Actor Identity	Identifies the cashier, supervisor, system job, or integration process that initiated the action.
Timestamp	Records the precise moment of the action in local store time and UTC.
Terminal / Register	Identifies the physical terminal where the action occurred.
Session Reference	Links the action to a specific cashier shift session.
Origin Context	Identifies whether the action came from barcode scan, manual entry, supervisor override, or sync replay.
Before / After Snapshot	Captures the state of the session, drawer, or receipt before and after the change.
Reason Code	Captures the business justification for overrides, voids, discrepancies, and forced actions.

Audit Invariants

• Audit log entries are append-only. They can never be edited or deleted.
• Closed sessions retain a complete lineage of opening float, all cash movements, transactions, closing count, and discrepancy.
• Voided line items, cancelled receipts, and refund transactions are permanently linked to their original context.
• Supervisor overrides require dual authentication and are recorded with mandatory reason codes.
• Offline replay events include terminal sequence numbers and conflict resolution notes.

---

2. Cash Drawer Discrepancy Handling

Drawer discrepancies occur when physical cash does not match the expected balance. Discrepancies are recorded, not overwritten, and resolved through compensating financial documents.

Discrepancy Types

Type	Definition	Typical Causes
Overage	Actual cash exceeds expected cash.	Incorrect change, unrecorded cash found, customer overpayment.
Shortage	Actual cash is less than expected cash.	Incorrect change, theft, unrecorded paid-out, miscount.
Balanced	Actual cash equals expected cash.	Correct operations and accurate counting.

Discrepancy Recording

At session close, the system computes:

$$ \text{Discrepancy} = \text{Actual Closing Cash} - \text{Expected Cash} $$

Discrepancy Value	Classification	Action
Positive	Overage	Recorded as overage; may be deposited or retained per policy.
Zero	Balanced	Session closes with no variance.
Negative	Shortage	Recorded as shortage; may require cashier acknowledgment or payroll deduction per policy.

Discrepancy Resolution Policy

Scenario	Resolution
Minor variance within tolerance	Tolerance applied; no further action.
Variance outside tolerance	Supervisor investigation; reason code required.
Pattern of shortages	Cashier retraining, disciplinary review, or operational audit.
Suspected theft	Security review; evidence preserved in audit trail.
System calculation error	Compensating adjustment in FMS; original session remains sealed.

Compensating Variance Journal

Discrepancies are not corrected by editing the session. Instead, FMS posts a compensating journal voucher:

Discrepancy	FMS Debit	FMS Credit
Overage	Cash / Bank Account	Overage Income Account
Shortage	Shortage Expense Account	Cash / Bank Account

This preserves the original session record while reflecting the financial reality in the General Ledger.

---

3. Offline Sync & Replay Policies

POS terminals must operate reliably during network disconnection. Offline transactions are replayed to central systems when connectivity returns, under strict consistency rules.

Offline Replay Principles

Principle	Description
Eventual Consistency	All valid offline transactions eventually reach central systems in order.
Monotonic Ordering	Transactions replay in strict terminal sequence order.
Idempotency	Duplicate replays do not cause double processing.
Conflict Detection	Central systems detect and flag conflicts requiring human resolution.
No Silent Loss	Missing or rejected transactions are explicitly reported, not ignored.

Replay Sequence Validation

For each terminal, the central system maintains the last accepted sequence $S_{last}$. A new transaction with sequence $S_{new}$ is processed as follows:

Condition	Action
$S_{new} = S_{last} + 1$	Accept and update $S_{last}$.
$S_{new} \leq S_{last}$ with identical payload	Idempotently acknowledge.
$S_{new} \leq S_{last}$ with different payload	Reject as conflict; flag for investigation.
$S_{new} > S_{last} + 1$	Reject; require backfill of missing sequences.

Conflict Resolution

When replay conflicts occur, the system applies the following priority:

1. Customer-Facing Truth: The receipt issued to the customer at the terminal is authoritative for price and tender.
2. Inventory Truth: WMS reconciles stock based on accepted transactions; conflicts may require manual stock adjustment.
3. Financial Truth: FMS posts based on accepted session totals; discrepancies are handled as variances.
4. Manual Override: Authorized supervisors may resolve conflicts with documented reason codes.

Typical Offline Conflict Scenarios

Scenario	Cause	Resolution
Gift card spent elsewhere while offline	Customer used same gift card at another channel.	Transaction honored if possible; shortfall recovered via alternative tender or store credit.
Store credit exhausted during offline period	Customer redeemed remaining store credit online.	Refund limited to available balance; remainder handled as return credit or cash per policy.
Price changed during offline period	Central price update occurred while terminal was offline.	Original snapshot price honored; price variance logged for margin analysis.
Promotion expired during offline period	Discount rule no longer valid.	Original promotion honored if locally active; promotional variance logged.
Product discontinued during offline period	Product removed from catalog while terminal offline.	Sale honored if local cache was valid; WMS handles final inventory disposition.

---

4. Compensating Strategies

The POS domain does not allow retroactive editing of closed sessions or completed receipts. Corrections follow formal compensating strategies.

Why Record Destruction Is Forbidden

Deleting POS records would break:

• The immutable audit trail required for cash and tax accountability.
• The sequential integrity of terminal transaction numbering.
• The ability to reproduce historical Z-reports and bank deposits exactly.
• The trust relationship between cashiers, supervisors, and finance.

Correction Strategies

Correction Scenario	Compensating Document / Action	Description
Incorrect change given	Cash Variance Journal + operational note.	Discrepancy recorded at close; FMS posts variance.
Wrong item rung up	Return/Refund Receipt + new sale receipt.	Original sale remains; correction processed as separate transactions.
Wrong tender recorded	Tender Correction Record + FMS adjustment.	Original receipt remains; compensating entry posted.
Post-close price dispute	Refund/Adjustment Receipt in new session.	Original session remains sealed.
Missing cash drop record	Drop Correction Record with supervisor approval.	Drop recorded retroactively with audit trail; session variance adjusted in FMS.
Offline transaction rejected on replay	Replay Exception Record + manual resolution.	Conflict documented; compensating sale or refund issued.

---

5. End-of-Day Reconciliation

At the end of the business day, all closed sessions are aggregated into a store-level settlement.

Settlement Elements

Element	Source	Purpose
Total Sales	Sum of all PosSaleCompleted events.	Revenue reporting.
Total Refunds	Sum of all PosSaleRefunded events.	Contra-revenue reporting.
Net Sales	Total Sales minus Total Refunds.	Net revenue.
Tender Summary	Sum by tender type across sessions.	Deposit and reconciliation.
Tax Collected	Sum of tax lines by category.	Tax remittance.
Cash Drops	Sum of PosCashDropRecorded events.	Safe deposit verification.
Petty Expenses	Sum of PosPettyExpenseRecorded events.	Expense verification.
Discrepancies	Sum of overages and shortages.	Variance reporting.
Depositable Cash	Computed net cash for bank deposit.	Bank reconciliation.

Reconciliation Workflow

flowchart TD
    A[All Sessions Closed] --> B[Aggregate Session Totals]
    B --> C[Compare Tender Totals to Acquirer Settlements]
    C --> D{Match?}
    D -->|Yes| E[Prepare Deposit]
    D -->|No| F[Investigate Variance]
    F --> G[Document Reason Code]
    G --> E
    E --> H[Post to FMS]
    H --> I[Settlement Complete]

---

6. Regulatory & Compliance Alignment

The POS audit and reconciliation model supports common retail regulatory requirements:

Requirement	Supported Capability
Sales Tax Reporting	Itemized tax breakdown by jurisdiction and category.
Cash Handling Controls	Dual-control drops, supervisor overrides, and discrepancy tracking.
Receipt Integrity	Immutable receipt snapshots with sequence numbers.
Fiscal Period Closing	Sealed session and daily settlement totals.
Fraud Detection	Audit trail of voids, refunds, overrides, and discrepancies.
Payment Card Security	Tender data limited to last-four digits and authorization tokens; no full PAN retained.

---

7. Summary

The POS domain in Obelaw is a rigorous, event-driven, edge-resilient bounded context that enforces retail correctness through immutable sessions, sealed receipts, non-negative tender validation, monotonic offline sequences, and formal discrepancy handling. It remains isolated from central operational and financial contexts via an Anti-Corruption Layer and emits only the retail facts necessary for inventory deduction, financial settlement, customer loyalty accrual, and enterprise reporting.