MyHoreca Pay Roadmap

Executive summary

MyHoreca Pay is a production-oriented financial operations product for Indonesian bank statement recognition and Syrve/iiko payment reconciliation. The core pipeline — import → normalize → match → allocate → post → reconcile — is implemented end-to-end. Live tests have proven the read path and test-only payment write (PASS_WRITE). Reconciliation is not yet safe (FAIL_RECONCILE on the first live write). Registered runtime capability is now always on; production execution still requires owner procedure, scoped RBAC, mandatory manual approval and all business/transport checks.

This document is the single source of truth for product phases, readiness criteria, and near-term priorities. The product workflow source of truth is ADR: Product workflow v1. This roadmap is grounded in the current repository state as of 2026-06-19.

Current product state

Area	Status	Evidence	Notes
Backend layered architecture	Done	codegraph/manifest.yaml	Domain / Application / Infrastructure split; architecture tests
Bank statement import MVP	Implemented	docs/docs/backend/api.md, bank adapters (CIMB/BCA/Permata/Mandiri)	Needs more bank adapters
Syrve/iiko bridge	Implemented	docs/docs/architecture/syrve-payment-orchestration.md, live reports	Secret via env:VAR ref
Document sync	Live tested	write report — 13 docs synced	Read path healthy after auth fixes
Payment allocation	Implemented	API + PaymentAllocationService	Needs UX hardening
Test payment write	PASS_WRITE	write report	Test environment only
Reconciliation	FAIL_RECONCILE	write report	OUTGOING_INVOICE readback needs hardening
Anomaly control	Implemented / partial	docs/docs/architecture/payment-anomaly-control.md, API, live verification	Critical anomaly + retry gate verified once
Notifications	Implemented / partial	API, NotificationBell, live report	Needs UX verification
Scoped RBAC / tenancy	Missing / next	Flat User / Role in Entities.cs	Critical before beta
Production write	Not approved	mandatory approval and safety controls	Future controlled phase

Live test summary:

Test	Date	Result
Read-only smoke (first run)	2026-06-19 09:28	FAIL — auth; infra fixes applied
Read-only rerun	2026-06-19 09:55	FAIL_AUTH — diagnostic improved
Test payment write	2026-06-19 15:30	PASS_WRITE / FAIL_RECONCILE

What is already built

Backend

• Layered .NET solution: Domain, Application, Persistence, BankStatements, Infrastructure, Api, Gateway, IikoConnector
• UUID v7 policy for entity IDs (IUuidGenerator)
• JWT auth with permission-based authorization (PermissionNames)
• Audit log for payment and integration actions
• Bank statement import pipeline: format detection, registered bank adapters, normalized transactions
• Counterparty matching (rules + manual match)
• Payment allocation preview/confirm with partial/overpayment line fields
• Syrve orchestration: connections, bridge to IikoConnector, document sync worker, document snapshots
• Payment candidates, posting queue, posting worker, reconciliation worker
• Payment write controls: mandatory manual approval, scoped RBAC, idempotency, payable/amount/allocation/anomaly checks, server applicability and method-specific preflight
• Payment anomaly entity + app service + API
• App notifications + bell UI component
• Outbox worker for reliable side effects
• Architecture tests + Syrve unit tests

Frontend

• React SPA operational workspace with routes for dashboard, bank statements, matching, allocations, Syrve connections/documents/postings, anomalies, reconciliation, audit log, settings
• TanStack Query API hooks (usePayApi, useSyrveApi)
• Reusable UI primitives (DataTable, StatusBadge, NotificationBell, etc.)
• Russian operator-facing status messages (statusMessages.ts)

Documentation & tooling

• VitePress docs portal
• Codegraph manifest for AI/developer navigation
• Syrve live test playbooks and dated reports
• Environment variable reference for Syrve/Iiko runtime profiles

What has been live-tested

1. Bridge — Pay SyrveConnection ↔ IikoConnector IikoRestaurantConnection with env: secret refs
2. REST/RPC auth — after Iiko runtime env block configured; diagnostics surfaced in health API
3. Document sync — 13 documents synced on test iiko (https://200-137-733.iiko.it)
4. Method-specific write preflight — WriteEligible with ForbiddenButNonBlocking for generic RPC verify 403
5. Dry-run → approve → worker write — OutgoingDocumentPayment posted with ExternalPaymentId
6. Reconcile failure — reconciliation_amount_mismatch; live readback lag / inconsistent unpaid sum
7. Anomaly control — Critical overpaid_after_write anomaly created; notifications sent; retry blocked on open critical anomaly

What is not ready yet

• Scoped multi-tenant RBAC — no Organization, Location, OrganizationQuota entities; flat global roles only (Admin, Accountant, Operator, Viewer)
• Ownership enforcement — OrganizationId/LocationId exist on anomalies/notifications only; not on imports, connections, allocations
• Real Indonesian bank adapters — Permata, Corporate DC, Multi-account CR/DB + Demo (Beta; pilot validation pending)
• Import quality / parser confidence UI — implemented (dashboard widgets, import list/detail tabs)
• Stable OUTGOING_INVOICE readback — reconcile uses getUnpaidSumForAGivenInvoice; may need alternate probes or backoff
• Transaction type guard on write RPC response
• PASS_WRITE + PASS_RECONCILE repeated in test
• BackOffice verification workflow — API exists; operator procedure not fully productized
• Production write enablement — per-org/per-location flags do not exist
• Beta pilot runbooks — UAT checklist, production readiness, release checklist added (MHPAY-23); live UAT evidence pending

Current blockers and risks

Risk	Severity	Mitigation phase
Payment write without org/location scope	Critical	Phase 2 — Scoped RBAC
Reconciliation false negatives (readback lag)	Critical	Phase 4 — readback strategy + backoff
Treating always-on capability as authorization	Critical	Phase 6 — controlled production procedure
Only demo bank adapter	High	Phase 1 — partially done (Beta adapters; pilot pending)
Flat Admin role has all permissions	High	Phase 2 — scoped roles
Optimistic evidence mistaken for confirmation	Medium	Documented; anomaly layer partially mitigates
Duplicate test writes on same document	Medium	Phase 4 — duplicate-write block (partial via anomaly gate)
Iiko transport/credential configuration complexity	Medium	Playbooks + env docs (done); needs runbook
Pre-existing failing tests (if any)	Low	Phase 0 cleanup

Do not approve production postings until Phase 6 criteria are met. Always-on runtime capability is not sufficient — scope, owner procedure, manual approval and every safety check remain mandatory.

Roadmap phases

Phase 0 — Foundation

Status: mostly done.

Scope:

• Layered backend architecture
• Frontend shell
• Gateway (YARP)
• Auth baseline (JWT + permissions)
• UUID v7 policy
• Audit baseline
• Bank import MVP
• Syrve bridge
• Document sync
• Payment allocation
• Posting worker
• Reconciliation worker
• Test/live reports

Remaining:

• Cleanup pre-existing failing tests if any
• Keep codegraph/docs current

---

Phase 1 — Bank Statement Intelligence

Status: Beta implemented (2026-06-19). Pilot validation on live exports pending.

Goal: Stable recognition of Indonesian bank statements.

Scope:

• Bank adapter registry
• Format detector (exists)
• Real adapters for uploaded samples
• Permata CSV/TXT/MT940-like
• Corporate explicit debit/credit CSV
• Multi-account CR/DB CSV
• Duplicate detection
• Counterparty extraction
• Import quality report
• Parser confidence report

Deliverables:

• docs/docs/architecture/bank-statement-parsing.md
• Adapter test suite + sanitized fixtures
• Import quality UI + supported banks dashboard

---

Phase 2 — Organization / Location / Scoped RBAC / Quotas

Goal: Multi-tenant safety.

Scope:

• Organization, Location, OrganizationQuota
• Scoped role assignment
• Roles: MegaAdmin, MegaManager, OrganizationAdmin, LocationAdmin, PaymentOperator, Accountant, Viewer
• Scope-aware API filters
• Quota enforcement
• Ownership fields on business entities

Critical because: payment write without organization/location scope is unsafe.

---

Phase 3 — Syrve Read / Match / Allocation Product

Goal: Accountant operational workflow.

Scope:

• Syrve/RMS connections UI (partial — exists)
• Health/diagnostics/sync
• Debt/document screens
• Candidates
• Matching
• Allocation UI
• Partial payment
• Overpayment handling
• Manual correction
• Evidence preview

---

Phase 4 — Test Payment Write Hardening

Goal: PASS_WRITE + PASS_RECONCILE in test.

Scope:

• Method-specific write preflight (done)
• Transaction type guard
• Outgoing invoice readback strategy (getPaymentTransactions / getAbstractDocument probes)
• Reconciliation retry/backoff (config exists; needs tuning)
• Anomaly dashboard (partial)
• Notifications (partial)
• BackOffice verification workflow
• Duplicate write blocking

---

Phase 5 — Beta Readiness

Goal: Product usable by controlled pilot customers.

Scope:

• Scoped RBAC complete
• Import/matching/allocation UX usable
• Anomaly/notification UX complete
• Support/admin diagnostics
• Audit coverage
• Deployment docs
• Backup/restore notes
• Operational runbooks

---

Phase 6 — Controlled Production Write

Goal: Production payment write only after strict gates.

Scope:

• Per-organization production write flag
• Per-location production write flag
• Owner approval
• Accountant approval
• Anomaly-free test history
• Support runbook
• Rollback/manual correction procedure
• Production write evidence
• Production write monitoring

Important: removed env/config gates are not a production control. Production execution needs scoped authorization, explicit owner procedure and mandatory approval.

Beta readiness criteria

Beta means: controlled pilot customers can run import → match → allocate → test write (where enabled) with scoped access and anomaly safety. Not production write.

Beta readiness checklist

• [ ] Scoped RBAC implemented
• [ ] Organization/location ownership enforced
• [ ] Bank adapters for first real pilot banks
• [ ] Upload/import quality report
• [ ] Syrve read sync stable
• [ ] Allocation UI usable
• [ ] Test payment write has PASS_WRITE + PASS_RECONCILE
• [ ] Anomaly dashboard complete
• [ ] Notifications complete
• [ ] Audit complete for payment actions
• [ ] Support/admin diagnostics complete
• [ ] Deployment/runbook documented

Production readiness criteria

Production-ready (non-write) means: same as beta plus stable operations, scoped tenancy, and no open critical anomalies in pilot history.

Production-ready with payment write requires all Phase 6 items in addition to the production payment write criteria below.

Production payment write criteria

Production write remains unapproved until all are true:

• [ ] Scoped RBAC complete
• [ ] Organization/location quotas complete
• [ ] Per-organization production write enablement
• [ ] Per-location production write enablement
• [ ] Payment write approval workflow complete
• [ ] Idempotency verified
• [ ] Evidence verified
• [ ] Reconciliation stable
• [ ] Anomaly control stable
• [ ] BackOffice verification procedure documented
• [ ] Test environment PASS_WRITE + PASS_RECONCILE repeated
• [ ] Support runbook ready
• [ ] Owner explicitly approves production pilot

Always-on capability is not authorization. Production write must be scope-valid and explicitly approved under the production procedure.

Near-term iteration plan

Iteration 1 — Roadmap & Product Map

Create roadmap, current-state, product-scope, user-roles docs. (this iteration)

Iteration 2 — Scoped RBAC Foundation

Organization, Location, Quota, scoped roles, ownership fields, scoped API filtering.

Iteration 3 — Anomaly Control Completion

Payment anomaly UI, notifications, duplicate-write block, BackOffice verification, reconciliation backoff.

Iteration 4 — Bank Adapter Expansion

Implement real Indonesian bank adapters from available samples and import quality reports.

See also: Implementation Backlog.

Ownership / responsibilities

Area	Owner role (target)	Current state
Platform / quotas / production gates	MegaAdmin	Admin role (global)
Customer onboarding / pilot	MegaManager	Not implemented
Org settings / connections / users	OrganizationAdmin	Admin
Location operations	LocationAdmin	Not implemented
Bank upload / matching / allocation prep	PaymentOperator	Operator
Approve posting / reconcile / anomalies	Accountant	Accountant
Read-only reporting	Viewer	Viewer
IikoConnector transport	Backend / integration	Implemented
Docs / codegraph	All developers	Maintained per AGENTS.md

Glossary

Term	Meaning
PASS_WRITE	iiko RPC accepted payment (PostedAtUtc, ExternalPaymentId)
PASS_RECONCILE	Live readback matches ExpectedUnpaidAmountAfter
Bridge	Link between Pay SyrveConnection and IikoConnector IikoRestaurantConnection
Posting	SyrvePaymentPosting — queued payment write job
Anomaly	PaymentAnomaly — detected mismatch requiring operator review
Preflight	Method-specific write eligibility check before dry-run
Scoped RBAC	Roles limited to organization and/or location
Beta	Pilot usage without production write
Production write	Live payment posting to Production Syrve/iiko connections

Related documents

• ADR: Product workflow v1
• Current architecture state
• Product scope
• User roles
• Implementation backlog
• Syrve payment orchestration
• Payment anomaly control
• API reference