Expense management specification

Who uses this, and how they get access

Factory, sales and office workers use one employee identity for time and expenses. The journeys below define the target experience. Mobile, email-free access, shared terminals and offline capture are requirements in development, not a statement of release availability.

Factory workers

At the start of a shift, identify yourself at an employer-provided terminal or on the mobile app, then start work. Record breaks and the end of the shift, including overnight work. A personal phone or email must not be required. The terminal returns to its locked start screen after each action; it must never expose another worker’s hours, receipts or account.

For an occasional purchase such as approved equipment or travel, use the app or a private session on a company device to attach the receipt. If assistance is needed, an authorized colleague records who paid, who entered the claim and why; the worker confirms it before submission. A supervisor cannot claim a worker’s reimbursement as their own. Assisted capture is proposed work.

Sales and field workers

Use the iOS or Android app between customer visits: start or correct time, choose a project, distinguish working travel from private travel, and photograph a receipt immediately. Review the amount, currency, category and who paid before submitting. A visit or a GPS position must not automatically become approved work. Travel-time eligibility follows the employer’s agreed policy.

Without reception, retain time events and receipt drafts securely on the device and label them “not yet synced”. Reconnection must not duplicate hours or claims. Upload failure keeps the draft available for retry; submission waits for server confirmation and any required attachment. No offline item may appear approved or reimbursed.

Office workers

Use the web app on a computer for daily time entry, project allocation, weekly review and receipt upload. The mobile app is optional for capturing receipts or time away from the desk. Company email is convenient, but having a desk must not determine which identity or access rights a worker receives. Employee time confirmation and expense submission remain separate actions.

Account creation without company email

Current source behavior: registration, invitations and password recovery depend on an email identity. A personal email can satisfy the address field; a company-domain address is not required by the registration schema. The invitation form may omit the email field because the invitation already supplies it. This is not email-free registration. Phone-only, employee-number and kiosk sign-in are not implemented.

Target requirement: an administrator creates or imports the worker into the correct organization, assigns a manager, work location, schedule and enabled modules, then gives them a single-use activation code in person or through an approved channel. The worker activates their own account, chooses their language and sets a private credential. No invented email, shared supervisor account, personal phone or employee purchase of a subscription is required. A code must never let someone choose their own employer or role.

Recovery, shared devices and leaving the company

Proposed sign-in: organization code, employee identifier and a private credential. A short PIN is restricted to an enrolled company terminal with attempt limits and a locked-down session; an employee number or badge alone is not proof of identity. Activation codes expire after 48 hours and one use. After identity verification, an authorized administrator can issue a replacement and revoke old sessions; every recovery is logged. Never display or email the old credential.

A lost device can be revoked without deleting the worker’s records. On departure, revoke organization access and prevent queued mobile actions from being accepted; route unsettled time and expenses to the named manager and finance owner. Define how former workers obtain their own statements through HR. A worker moving to another employer must never inherit access to the previous organization’s data.

App scope and rollout acceptance

The existing delivery direction is a React Native app for iOS and Android, alongside the web app. Proposed first employee release: activation and sign-in, time and breaks, corrections, weekly review, receipt capture, expense submission and status. Managers and administrators start on the web. Installation on a personal device is optional; the employer supplies a usable alternative. Native release, email-free access and terminal operation each need their own acceptance test.

Before rollout, demonstrate three complete journeys: a factory worker with no email or phone finishes a shift and submits a receipt; a salesperson records a visit and receipt offline and syncs exactly once; an office worker corrects a week and follows a reimbursement. Verify all four interface languages, readable errors, keyboard and screen-reader access, no cross-worker data after terminal handover, and visible review outcomes without email notifications. These are release gates, not completed tests.

Capture and receipt review

Current: employees create their own draft with merchant, date, amount in the organization currency, category and payment method. Description, receipt, project and billable flag add context; foreign receipt amount and currency can be retained separately. Categories cover travel, meals, accommodation, transport, software, office supplies, entertainment, training, equipment and other purchases.

Current: scanning JPEG, PNG, WebP or PDF documents requires both Expenses and AI. The multipart scanner accepts files up to 10 MiB. It extracts basic expense fields plus supplier/customer details, invoice dates and numbers, tax breakdowns, line items, payment details, readable source text and additional label/value fields. Amounts in invoice details remain in the invoice currency. The original attachment is retained and extracted fields can be corrected.

Current: the extraction contract asks for unknown values to remain null, warnings for ambiguity and no invented date, currency or tax. This is a model instruction, not a guarantee of correct extraction. The employee checks every field before saving or submitting; manual capture remains available without AI. Required: test unreadable and mixed invoices, show warnings, preserve the draft on failure and never treat a suggestion as approval. A scanned credit note does not establish a supported refund workflow.

Amounts, currencies and who paid

Current: personal funds and company card are distinct payment methods. A foreign receipt retains its original amount and currency, but no exchange-rate service converts it automatically. The employee must check and enter the organization-currency amount; a scan can initially copy the foreign numeric total into that field. The billable flag identifies a possible client charge and does not create an invoice.

Required: show both currency codes beside their amounts and require explicit confirmation of a foreign-currency conversion. Record the rate, date, source or manual reason and rounding used. For EUR 100 reimbursed as CHF 95, approval, policy checks and finance totals use CHF 95 while the receipt remains EUR 100. Preserve the currency with each historical amount if the organization changes its default. Do not sum unrelated currencies or treat card spending as money owed to the employee.

Category policy and exceptions

Current: administrators configure category blocking, a maximum amount and a receipt threshold. A blocked category or a missing receipt strictly above the receipt threshold prevents submission. Exceeding the maximum is a warning and still allows submission for review. At the exact threshold, the “above” condition does not trigger. A category without a configured rule has no category-policy restriction.

Required: explain each violation and retain the draft when submission is blocked. Show the policy version used at submission and review; changed rules must not silently rewrite a historical decision. An over-limit approval needs a recorded reason. A missing-receipt exception needs a designated reviewer and evidence, not an invented attachment. These versioning and exception procedures are proposed; current policy warnings are evaluated live when read and blocking checks run at submission.

Draft, review and reimbursement

Current: a new claim is Draft. Its owner can edit or delete Draft and Rejected claims, then submit them. Submission changes either state to Submitted and clears previous decision fields. A reviewer changes Submitted to Approved or Rejected; rejection requires a note in the form. The employee corrects a rejection and resubmits. Ordinary employees cannot edit Submitted, Approved or Reimbursed claims. Administrators can correct non-draft claims, including their own, without changing status; this correction permission does not allow self-approval.

Current: only an administrator can mark an Approved personal-funds claim Reimbursed, after payment outside Flipp. Company-card claims finish at Approved and cannot be reimbursed. Nobody can approve, reject or mark their own claim reimbursed. Required: preserve every decision and resubmission in history, reject stale or repeated transitions safely, and show “approved, awaiting payment” separately from “reimbursed”. Marking reimbursement must record the payment date and reference; it must never initiate a bank transfer.

Employee, manager and finance responsibilities

Current: employees manage their own editable claims. Managers review people in their managed hierarchy; administrators review the organization. Reports and Excel export use the same review scope. Expenses must be enabled for the organization. A finance job title does not grant access: reimbursement marking currently requires administrator permission, with self-review excluded.

Required: name a deputy when the manager is absent and a different approver for managers’ and administrators’ own claims. If none exists, keep the claim pending for an authorized organizational decision; do not bypass self-review controls. Propose a finance permission limited to payment tracking and relevant reports instead of requiring broad administration. Set review and payment deadlines per organization, show overdue queues, and remind or escalate without approving automatically.

Reports, corrections and finance handover

Current: reports filter dates, category and status and summarize by category, submitter, status and month. Excel includes expense and original amounts, payment method, status, project and reviewer, with additional sheets for invoice lines, taxes, extra fields and source text linked by expense ID. Administrator corrections store before/after values and actor/time atomically with the edit, reject stale versions and expose claim history. They preserve existing approval and reimbursement status. Reports including drafts or rejected claims are not payable balances; no payments or accounting sync are executed.

Required: finance receives an identifiable batch of approved personal-funds claims still unpaid, with claim IDs, currencies and included states reconciled to the report. Re-export must not cause another payment. Separate card spending and paid claims. A changed payable amount after approval must record a reason and trigger renewed review; a reimbursed claim needs an explicit adjustment preserving the paid amount. Current correction history alone does not meet those requirements because edits retain workflow status. Period close, payment date/reference and payment-batch controls remain proposed.

Privacy and product boundaries

Required: protect receipt access as strictly as the claim itself, including attachment links, exports and shared-device caches. Show what is sent for AI processing and provide manual entry if scanning is disabled or fails. Do not collect continuous location, personal activity or banking credentials to record time or an expense. Agree retention, authorized deletion, audit retention and access after departure with the customer before rollout; no retention period is promised here.

Not delivered by this specification: native apps, email-free accounts, kiosks, offline sync, mileage rates, per diems, advances, split claims, automatic duplicate detection, automatic tax/VAT determination, bank payments or accounting integrations. Reading printed tax and invoice details does not determine tax eligibility. AI never authorizes spending or reimbursement.

Expense acceptance scenarios

Release gates: prove a personal-funds claim from draft through rejection, correction, approval and reimbursement; a company-card claim must stop at approval. With maximum 100 and receipt threshold 50, 50 without a receipt does not trigger the threshold, 50.01 does, and 100.01 with a receipt warns but can be submitted. Verify the EUR 100 / CHF 95 case, a failed scan with manual completion, a failed upload and an offline retry without duplicates.

Also prove that a manager cannot see an unrelated team’s claim or receipt, another organization cannot retrieve an attachment or export, and nobody can review their own claim. Test an absent reviewer, concurrent decisions, an approved-amount correction, departure with an unpaid claim and a repeated finance export. Show the resulting stored history, worker-visible status and reconciled finance totals. These scenarios define the required result; their successful execution must be demonstrated before rollout.