MyHoreca Pay Product Scope

Problem

Indonesian hospitality businesses receive bank statements in many formats. Accountants must match incoming/outgoing bank transactions to open Syrve/iiko documents (invoices, outgoing invoices, service receipts) and post payments correctly. Manual work is error-prone; incorrect writes to iiko are hard to reverse and create financial risk.

MyHoreca Pay automates:

1. Bank statement import and normalization
2. Counterparty and document matching
3. Payment allocation with mandatory manual approval
4. Controlled, auditable payment write to Syrve/iiko
5. Reconciliation and anomaly detection when live state disagrees with expectations

Target users

Product roles (target model; see User Roles for current vs planned):

Role	Primary need
MegaAdmin	Platform control, quotas, production safety oversight
MegaManager	Pilot customer onboarding, cross-org support
OrganizationAdmin	Org setup, locations, Syrve connections, users
LocationAdmin	Location-scoped operations and connections
PaymentOperator	Upload statements, match, prepare allocations
Accountant	Approve postings, reconcile, resolve anomalies
Viewer	Read-only dashboards and reports

Current implementation: flat roles Admin, Accountant, Operator, Viewer without organization/location scope.

Core workflow

1. Admin creates organization/location.          [Phase 2 — not yet]
2. Admin connects Syrve/RMS.                   [Implemented]
3. System syncs open documents/debts.          [Live tested]
4. Operator uploads bank statement.            [Implemented — demo adapter]
5. System normalizes transactions.             [Implemented]
6. System suggests counterparty/document matches. [Implemented]
7. Operator prepares allocation.               [Implemented]
8. Accountant approves posting.                [Implemented — test only]
9. Worker posts payment to Syrve/iiko if allowed. [PASS_WRITE in test]
10. System reconciles.                         [FAIL_RECONCILE — in progress]
11. If mismatch — anomaly + notification + manual review. [Partially verified]

Roles

See User Roles for permissions and payment write rights per role.

Summary:

• Viewer — read only; no upload, approve, or write
• PaymentOperator — upload, match, prepare; no live write approval
• Accountant — approve, reconcile, manage anomalies within scope
• OrganizationAdmin — users, locations, connections within quota
• MegaAdmin — platform, quotas, production enablement (future)

Production write is not granted to normal roles in the current phase.

Main screens

Screen	Route	Status
Dashboard	/dashboard	Implemented
Bank statement upload	/bank-statements	Implemented
Import detail / transactions	/bank-statements/:id	Implemented
Counterparty matching	/name-matching	Implemented
Payment allocation preview	/payment-allocations/preview	Implemented
Payment allocations list	/payment-allocations	Implemented
Payment candidates	/payment-candidates/:bankTransactionId	Implemented
Syrve connections	/syrve/connections	Implemented
Connection health / bridge	/syrve/connections/:id	Implemented
Documents (unpaid/partial/paid)	/syrve/documents/*	Implemented
Document sync runs	/syrve/document-sync-runs	Implemented
Postings	/syrve/postings	Implemented
Posting detail (evidence, dry-run)	/syrve/postings/:id	Implemented
Reconciliation	/syrve/reconciliation	Implemented
Payment anomalies	/payment-anomalies	Implemented
Syrve references	/syrve/references	Implemented
Audit log	/audit-log	Implemented
Settings	/settings	Implemented

MVP scope

In scope (delivered or near-complete):

• Single-tenant operational workspace (no org isolation yet)
• Bank statement CSV import (CIMB, BCA, Permata, Mandiri)
• Counterparty matching
• Payment allocation preview/confirm
• Syrve connection registry + IikoConnector bridge
• Document sync and local snapshot read model
• Payment candidate suggestions
• Posting queue with approval gate and idempotency
• Worker-only payment write with mandatory approval and safety preflight
• Reconciliation worker + manual reconcile API
• Payment anomalies and notifications
• Audit trail for key actions
• JWT auth with permission checks

Explicitly out of MVP:

• Production payment write
• Multi-tenant scoped RBAC
• Real Indonesian bank adapters (beyond demo)
• Import quality analytics UI
• Mobile-optimized UX

Beta scope

Beta adds pilot-customer safety and usability:

• Scoped RBAC (Organization, Location, quotas)
• Real bank adapters for pilot banks
• PASS_WRITE + PASS_RECONCILE in test environment
• Complete anomaly and notification UX
• Import quality reports
• Support/admin diagnostics and runbooks
• Controlled test write per pilot org (not production)

Out of scope for now

• Direct Syrve/iiko UI replacement
• General ledger / full ERP
• Payroll
• Tax filing
• Non-IDR multi-currency treasury
• Automatic production write without human approval
• Refactoring IikoConnector internals
• Public self-service signup without MegaAdmin approval

Critical safety rules

1. Always-on is not authorization — registered Pay-host capability cannot bypass RBAC/scope or an owner-approved production procedure.
2. No synchronous write from UI — all writes go through worker + outbox after mandatory approval; new postings always start in ApprovalRequired.
3. Idempotency required — duplicate keys with different request hash are rejected.
4. Posted ≠ Reconciled — posting success does not mean financial confirmation.
5. Optimistic evidence is not truth — only liveReadback in evidence counts for reconcile.
6. Open Critical anomaly blocks repeat write on the same external document.
7. Secrets never in DB or docs — use PasswordSecretRef=env:VAR.
8. Audit trail for import, match, allocate, approve, post, reconcile, anomaly actions.
9. UUID v7 for new entity IDs — no client-generated backend IDs.
10. Server applicability and transport preflight — credentials, HTTP/RPC, method-specific checks and technical limits must pass for every write.

Related documents

• Roadmap
• User roles
• Current architecture state
• Syrve test payment write playbook