Service Layer medium complexity mobilebackend
1
Dependencies
1
Dependents
1
Entities
0
Integrations

Description

Service handling the coordinator attestation workflow for expense claims that exceed auto-approval thresholds. Provides methods to fetch the pending queue, submit approve or reject decisions, and subscribe to real-time queue updates via Supabase Realtime.

Feature: Travel & Expense Registration

expense-attestation-service

Summaries

The Expense Attestation Service gives coordinators a structured, auditable mechanism to approve or reject expense claims that fall outside automated thresholds — ensuring human judgment is applied where financial risk warrants it. By providing real-time queue updates, coordinators can act on pending claims immediately rather than discovering backlogs during periodic reviews, which reduces the average time-to-decision and unblocks employee reimbursements faster. Every approval or rejection is recorded with a coordinator identifier and optional comment, creating a transparent audit trail that supports internal controls and simplifies external audit responses. For organizations with distributed field teams, this service is the operational backbone of spend governance — reducing financial exposure from unchecked claims while maintaining a positive experience for claimants who receive timely notifications of outcomes.

The Expense Attestation Service is a medium-complexity service operating across both mobile and backend execution contexts, requiring careful consideration of environment-specific behavior. Its single dependency on expense-repository keeps the surface area manageable, but the Supabase Realtime subscription via `subscribeToQueueChanges(organizationId, callback)` introduces stateful connection lifecycle concerns — callers must handle subscription teardown, reconnection on network loss, and duplicate event delivery. The `getPendingQueue(organizationId)` method should implement server-side filtering scoped to the coordinator's organization to prevent data leakage across org boundaries. The `approveExpense` and `rejectExpense` methods should be idempotent — concurrent coordinator actions on the same expense (race conditions in multi-coordinator orgs) must be resolved at the repository layer, ideally with optimistic locking or a status-check-before-write pattern.

Claimant notification in the responsibilities list implies either a direct call to a notification service or an event emitted on expense status change; this dependency should be made explicit in the interface to avoid hidden coupling. The expense data model is the sole entity managed here — any schema evolution (new status values, comment length limits) flows directly through this service.

Responsibilities

  • Fetch pending attestation queue for a coordinator's organisation
  • Submit approve or reject decision with optional comment
  • Subscribe to real-time queue changes via Supabase Realtime
  • Notify claimant of decision outcome

Interfaces

getPendingQueue(organizationId)
approveExpense(expenseId, coordinatorId, comment)
rejectExpense(expenseId, coordinatorId, comment)
subscribeToQueueChanges(organizationId, callback)
getExpenseDetail(expenseId)

Relationships

Dependencies (1)

Components this component depends on

Dependents (1)

Components that depend on this component

Related Data Entities (1)

Data entities managed by this component

API Contract

View full contract →
REST /api/v1/expense-attestations 7 endpoints
GET /api/v1/expense-attestations Get pending attestation queue for coordinator
GET /api/v1/expense-attestations/:id Get attestation record details
POST /api/v1/expense-attestations Create attestation record when expense is submitted
PUT /api/v1/expense-attestations/:id Update attestation record (coordinator decision)
DELETE /api/v1/expense-attestations/:id Cancel an attestation record (admin only)
POST /api/v1/expense-attestations/:id/approve Approve an expense
+1 more