Finance guide

Finance is the venue-scoped money role. You read the bookings book and the money views, request refunds under the approval workflow, and read the operational metrics — without any floor, booking-writing or setup authority. The role is granted by an owner or org admin only; a manager cannot mint it (the manager grant ceiling is HOST/DOOR/READ_ONLY).

What the role holds

Permission	What it means for you
reservations.read	See bookings, guest lists, the service view and message delivery outcomes for your venue.
payments.refund.execute	Request refunds and read the finance money views.
reporting.read	Run aggregate operational and financial reports (no guest detail anywhere).
exports.download	A reserved download right — registered for this tier but no screen consumes it in this release (see What works today & known limits).

Everything else — writing bookings, the floor, check-in, the waitlist, staff, venue setup, privacy cases, bulk import/export, billing and approval authority — refuses with PERMISSION_DENIED (403).

Sign-in and first screen

Sign in at /app/login (plus a 6-digit code when two-step verification is on). You land on Your venues at /app and open your venue’s Today’s service board — read-only for you. Session basics: Your account & security.

Reading the money views

Money views are where this role lives. Host and door sessions are refused from them explicitly; yours are expected.

• Reservation payment status — the money view of one booking. The reservation badge and the payment badge are separate lines; receipts carry the provider’s own effect ids; captured, refunded, pending, disputed and remaining-refundable amounts are exact integer minor units; and a refund still at the provider reads PENDING — never “Refunded”.
• Finance transactions — the settled ledger for your venue, listed by transaction date (never the service date), with optional settled window and currency filters. Totals aggregate per currency and are never combined, and the pending queue lists every unresolved refund demand: awaiting decisions, pending at the provider and failed escalations.
• Refund intent queue — the demands for money back on this venue’s bookings, with origin, approval state and provider reference per row.
• Provider event inbox — the newest verified webhook envelopes per venue: safe references and processing checkpoints only; encrypted payloads never leave the database.

The machinery behind these views is in Payments (pilot posture).

Requesting refunds

Request a refund against a reconciled capture: the amount is bounded by the refundable balance (captured net minus settled refunds, open disputes and pending intents), checked under the venue lock. Two outcomes exist:

• At or below the venue’s delegation threshold the intent is born approved and proceeds on your authority.
• Above the threshold — and always when no threshold is set (the fail-closed default) — the intent waits for an ownership-tier decision. The approver can never be the requester.

Every human refund action demands MFA verified within the last 30 minutes on your live session. Without it the command refuses with MFA_REQUIRED: “Refunds demand fresh MFA — re-verify within the last 30 minutes.” Re-sign in with your authenticator code (or a recovery code) and continue. The full workflow, thresholds and the honest status labels: Refunds.

Keeping the pipeline honest

Two staff-fired passes complement the background worker, and both are safe to run: the payment-account sweep (every pending verified event, oldest first; unknown provider objects land in a FAILED exception queue, never dropped silently) and the refund sweep (approved intents move to the provider; a hard refusal fails terminally for manual resolution, never a second collection). Replaying either is a no-op. A refund that has reached the provider but not settled stays visibly PENDING_PROVIDER — the system never displays pending money as refunded.

Reports

You hold reporting.read, so the operational metric report renders for you: accepted parties, covers, cancellation split, lead times, waitlist conversion and per-currency money that is never combined. Metrics without an instrumented source (POS spend, online booking conversion, demand lost, resource utilization, actual occupancy) are reported as unavailable with their reason — never zero-filled — and zero-denominator rates read “not applicable”. See Reports & metrics.

What finance cannot do

• Approve or decline refunds, set the delegation threshold — the approval tier above you is owner/org-admin only, and it is never the requester (Refunds).
• Connect the payment account or touch the subscription — ownership-tier commercial acts (Subscription billing).
• Write bookings or run the floor — no reservations.write, no arrivals, seating, corrections or waitlist management.
• Move guest data in bulk — CSV import and the venue-wide FUTURE_BOOKINGS export need data.import/data.export, which finance does not hold (CSV import).
• Run privacy cases, manage staff, edit the venue — above the role’s purpose (Privacy, retention & deletion).
• See other venues — a venue outside your membership answers a plain 404, never a permission error.

During the pilot nothing here can move real money: the payment machinery runs end to end against sandbox providers with the capability gates closed, so amounts are exact and statuses are honest while charges stay off. The posture is summarized in What works today & known limits, and the error codes you may meet in Error codes & fixes.