Physical Asset Inventory Audit with Barcode/RFID Scanning

The control flow a finance team actually needs.

The ERP surface involved.

Mobile scanning app must work offline with sync on reconnect; each scan records timestamp, GPS coordinates, and user ID; asset tag supports barcode (1D/2D) and passive RFID; discrepancy report categorizes: confirmed present, not found, found not in register, location mismatch; photo attachment per scanned asset stored and linked to audit cycle; audit cycle has open/in-progress/closed states; system prevents posting prior-period depreciation for assets retired via audit adjustment; audit completion rate shown as percentage.

US and UK teams have different compliance hooks, but the same control problem.

US teams usually care about clean evidence for audit support, vendor records, payment controls, tax reporting, and management review. UK teams usually care about VAT-ready records, approval evidence, digital-record discipline, and traceable postings. The country-specific details differ, but the operating pattern is the same: the ERP needs controlled records, explicit ownership, defensible state changes, and evidence that survives beyond the person who completed the task.

The control matrix.

Audit evidence is a chain, not a folder.

asset_audit_cycles { id: string, external_id: string, entity_id: string, cycle_start_date: date, cycle_end_date: date, status: enum(OPEN,IN_PROGRESS,CLOSED), total_assets: int, scanned_count: int, completion_pct: decimal };
asset_audit_scans { id: string, cycle_id: string, asset_id: string, scanned_at: timestamp, gps_lat: decimal, gps_lon: decimal, scanned_by_user_id: string, condition: string, photo_url: string, discrepancy_type: enum(CONFIRMED,NOT_FOUND,FOUND_NOT_IN_REGISTER,LOCATION_MISMATCH) };
(reference, product may differ).

POST /v1/asset-audit-cycles { entity_id, cycle_start_date, external_id } -> 201 { id, status: OPEN };
POST /v1/asset-audit-cycles/{id}/scans { asset_tag_id, gps_lat, gps_lon, condition, photo_url } -> 201 { id, discrepancy_type };
GET /v1/asset-audit-cycles/{id}/discrepancy-report;
POST /v1/asset-audit-cycles/{id}/close -> 200 { status: CLOSED };
emits asset_audit.closed event;
offline sync supported via batch upload endpoint;
idempotent via external_id.

OPEN -> IN_PROGRESS -> CLOSED;
guard: CLOSED requires zero unresolved discrepancies or explicit override with controller approval;
prior-period depreciation blocked for assets retired via audit adjustment.

The useful version of this workflow is not only fast. It is inspectable. A controller, auditor, or operator should be able to move from source event to system record to state transition to final business outcome without guessing.

Implementation contracts.

`asset_audit_cycles` { id: string, external_id: string, entity_id: string, cycle_start_date: date, cycle_end_date: date, status: enum(OPEN,IN_PROGRESS,CLOSED), total_assets: int, scanned_count: int, completion_pct: decimal }; `asset_audit_scans` { id: string, cycle_id: string, asset_id: string, scanned_at: timestamp, gps_lat: decimal, gps_lon: decimal, scanned_by_user_id: string, condition: string, photo_url: string, discrepancy_type: enum(CONFIRMED,NOT_FOUND,FOUND_NOT_IN_REGISTER,LOCATION_MISMATCH) }; (reference, product may differ).

`POST /v1/asset-audit-cycles` { entity_id, cycle_start_date, external_id } -> 201 { id, status: OPEN }; `POST /v1/asset-audit-cycles/{id}/scans` { asset_tag_id, gps_lat, gps_lon, condition, photo_url } -> 201 { id, discrepancy_type }; `GET /v1/asset-audit-cycles/{id}/discrepancy-report`; `POST /v1/asset-audit-cycles/{id}/close` -> 200 { status: CLOSED }; emits `asset_audit.closed` event; offline sync supported via batch upload endpoint; idempotent via `external_id`.

`OPEN -> IN_PROGRESS -> CLOSED`; guard: CLOSED requires zero unresolved discrepancies or explicit override with controller approval; prior-period depreciation blocked for assets retired via audit adjustment.