DuitNow-native Accounts Receivable & Credit Control

The selected idea, restated as a product: a Malaysian SME distributor sends 30–90 day credit to its business customers. Chasing late payment today means someone manually checking a spreadsheet, texting a buyer, then matching the bank statement by eye days later. This product automates that loop end to end, in Malaysian Ringgit, over WhatsApp, with a DuitNow QR code attached to every chase.

Problem

Late B2B payment is routine in Malaysia and the tools built to fix it (Chaser, Gaviti, Kolleno, TreviPay) are real, funded, and well-built — for a USD-billing enterprise with a live bank-API feed. None of them speak DuitNow, reconcile a Maybank or CIMB statement, or price for a RM2–20m/yr distributor. The gap is not "AR software doesn't exist," it's "AR software doesn't exist for this buyer."

Target customers

SME distributors and wholesalers in Malaysia extending 30–90 day terms to other businesses, roughly RM2–20m/yr revenue. The economic buyer is the finance manager or, at this size, the owner directly.

Core value proposition

Get paid faster without hiring a collections clerk: automatic ageing visibility, reminders that already carry a scannable DuitNow QR code, and a reconciliation view that tells you which invoices are actually settled — without replacing the accounting software already in use.

User roles

Key business rules

• An invoice belongs to exactly one buyer customer, who belongs to exactly one distributor account — no invoice is ever visible across accounts.
• An invoice is overdue the day after its due date and stays in the ageing bucket until a payment fully or partially settles it or it is manually written off.
• A reminder is scheduled, never sent silently without a visible log entry the finance staff can audit.
• A bank transaction can match at most one invoice; an invoice can be settled by more than one transaction (partial payments).

Minimum Sellable Product (MSP)

A finance manager can load their open invoices (CSV or manual entry), see them ranked by age, trigger a WhatsApp/email reminder carrying a DuitNow QR code, and upload a bank statement to mark invoices paid. That alone is sellable — it replaces the spreadsheet-plus-manual-WhatsApp workflow on day one.

Nothing here is added because a competitor has it — each P0 item is load-bearing for the MSP's single promise: see what's owed, chase it, confirm it landed.

A web tool that chases unpaid invoices for you and tells you the moment they're actually paid. Load your open invoices, it ranks them by how overdue they are, sends a WhatsApp or email reminder with a DuitNow QR code attached so the buyer can pay in two taps, and when you upload your bank statement it matches payments back to invoices automatically.

A distributor or wholesaler, roughly RM2m–RM20m a year in revenue, who gives their own customers 30 to 90 days to pay and currently chases that money by spreadsheet and manual WhatsApp messages. The person who signs is the finance manager, or the owner directly in a smaller shop.

• Nobody remembers to chase an invoice until it's badly overdue, because there's no single ranked view of who owes what and for how long.
• Chasing is manual — someone has to open WhatsApp, find the right contact, write the message, and remember to attach payment details.
• Reconciling a bank statement against outstanding invoices by eye is slow and error-prone, so "has this actually been paid?" is often answered a day later than it should be.

1. Load invoices — either upload a CSV from your existing books or type them in directly.
2. The dashboard sorts every open invoice by age: current, due soon, overdue.
3. On a schedule you set, the system sends a WhatsApp or email reminder with a DuitNow QR code the buyer scans to pay instantly.
4. When money arrives, upload your bank statement — the system matches each transaction to the invoice it settles and marks it paid.

• Built around DuitNow and Malaysian bank statements — not a US tool with a currency symbol swapped.
• Priced for a RM2–20m distributor, not an enterprise AR department.
• Doesn't replace the accounting software already in place — it sits on top, reading what's already there.
• A reminder that includes a working QR code gets paid faster than a text that says "please settle your account."

• Invoice import (CSV) and manual entry, single currency (MYR)
• Ageing dashboard — current / due soon / overdue
• Scheduled WhatsApp and email reminders with a DuitNow QR code on each one
• Bank statement upload with invoice matching, including partial payments

• No live, automatic bank feed — statements are uploaded by the customer, not pulled automatically, at launch
• No direct plug-in to SQL Account, AutoCount, or similar accounting software at launch — that's a fast-follow once the first customers confirm which software they actually run
• No multi-currency and no formal dispute/credit-note workflow at launch

1. Sign up and enter company details.
2. Import their existing customer list and open invoices (CSV template provided, or type them in).
3. Set the reminder schedule (e.g. 7 days before due, on due date, 7/14/30 days overdue).
4. Send the first batch of reminders and watch the ageing dashboard update as payments come in.

Expect to sit with the first few pilot customers while they import their first invoice batch — the CSV template won't match their export format perfectly on the first try.

6–8 weeks to an MVP a pilot customer can actually use, assuming the DuitNow QR question above resolves quickly and the first 2–3 real bank statement samples are in hand before week 5 (statement parsing is the one part of this build that can't be estimated from a spec alone — see the technical roadmap).

• At launch, "reconciliation" means uploading a statement file, not a live bank connection — set that expectation in the pitch.
• The system reads invoices and bank data you give it; it does not talk to your bank or your accounting software automatically yet.
• Pricing assumes the customer already has a bank statement export they can download (CSV or similar) — a customer who can only get a paper/PDF statement from their bank branch is a harder onboarding and should be flagged before signing them.

Six flows, drawn to the actual product above — not a generic SaaS template.

A. Complete customer journey

flowchart LR
  A[Hears about us via
distributor assoc. or
accounting-firm referral] --> B[Books a demo with
commercial founder]
  B --> C{Signs up for
trial?}
  C -- no --> Z[Stays manual —
follow up in 30 days]
  C -- yes --> D[Onboards: imports
invoices + sets reminders]
  D --> E[Sends first reminder batch]
  E --> F{Gets paid faster
in first 30 days?}
  F -- no --> G[Churns at trial end]
  F -- yes --> H[Converts to paid plan]
  H --> I[Monthly: uploads bank
statement, reviews ageing]
  I --> J[Renews month over month]
    

B. Customer onboarding

flowchart TD
  A[Create account] --> B[Enter company + buyer
customer list]
  B --> C{Has invoice
export file?}
  C -- yes --> D[Upload CSV]
  C -- no --> E[Enter invoices manually]
  D --> F{Import
validates?}
  F -- no --> G[Show row-level errors,
fix and re-upload]
  G --> F
  F -- yes --> H[Set reminder schedule
+ WhatsApp/email]
  E --> H
  H --> I[Review ageing dashboard]
  I --> J[Send first reminder batch]
    

C. Core product operation — the ageing/reminder/reconciliation loop

flowchart TD
  A["Invoice created
(import or manual)"] --> B[Scheduler computes
age bucket daily]
  B --> C{Due date
approaching or
passed?}
  C -- no --> B
  C -- yes --> D[Generate reminder
+ DuitNow QR]
  D --> E[Send via WhatsApp/email]
  E --> F[Log sent reminder]
  F --> G{Bank statement
uploaded?}
  G -- no --> B
  G -- yes --> H[Parse transactions]
  H --> I{Transaction matches
an open invoice?}
  I -- yes, confident --> J[Auto-mark invoice
paid/partially paid]
  I -- low confidence --> K[Queue for manual match]
  J --> L[Invoice leaves
ageing dashboard]
  K --> M[Finance staff
confirms match]
  M --> L
    

D. User roles and permissions

flowchart LR
  subgraph Owner
    O1[Manage billing]
    O2[Invite/remove users]
    O3[All finance-staff actions]
  end
  subgraph FinanceStaff[Finance staff]
    F1[Manage customers]
    F2[Manage invoices]
    F3[Send/schedule reminders]
    F4[Upload statements,
confirm matches]
  end
  Owner --> FinanceStaff
    

E. Subscription and payment process

flowchart TD
  A[Trial signup] --> B[14-day trial,
full P0 feature set]
  B --> C{Converts before
trial ends?}
  C -- no --> D[Account downgrades
to read-only]
  C -- yes --> E[Owner enters payment
method via gateway]
  E --> F[One-time setup fee
RM1,500 charged]
  F --> G[Monthly plan billed
RM249-499 by volume]
  G --> H{Payment
succeeds?}
  H -- no --> I[Retry + email alert,
then suspend after
grace period]
  H -- yes --> J[Active — next billing
cycle in 30 days]
    

F. Administrative workflow (our own ops)

flowchart TD
  A[Pilot customer
signs up] --> B[Founder manually
verifies account +
reviews first CSV import]
  B --> C{Import clean?}
  C -- no --> D[Founder fixes template
or assists customer]
  C -- yes --> E[Monitor reminder
delivery + bank-match
accuracy for 2 weeks]
  E --> F{Any failed
WhatsApp sends or
mismatches?}
  F -- yes --> G[Manual fix +
log as a product bug]
  F -- no --> H[Hand off to
self-serve]
    

A modular monolith on managed infrastructure — nothing here justifies microservices, a job queue cluster, or a dedicated data pipeline at pilot scale.

Recommended stack

flowchart LR
  subgraph Client
    Browser
  end
  subgraph Vercel
    NextApp["Next.js app
(UI + API routes)"]
    Cron["Vercel Cron
(daily ageing + reminder scheduler)"]
  end
  subgraph DataLayer[Data layer]
    PG[(Postgres
Neon/Supabase)]
    Blob[(File storage
CSV + statements)]
  end
  subgraph External[External services]
    WA[WhatsApp Business
Platform API]
    Email[Email provider
e.g. Resend]
    Pay[Billing gateway
CHIP/Stripe]
    QR[DuitNow QR issuer
— TBD, see B.10]
  end
  Browser -->|HTTPS| NextApp
  NextApp --> PG
  NextApp --> Blob
  Cron --> PG
  Cron --> WA
  Cron --> Email
  NextApp --> Pay
  NextApp --> QR
    

Security

• Every table carrying tenant data has an account_id column; every query is scoped to the authenticated user's account_id — enforce this at the database layer with row-level security, not only in application code.
• Uploaded bank statements and invoice CSVs contain real customer names and amounts — encrypt at rest (both Neon and Supabase do this by default) and never log full file contents.
• WhatsApp and email are one-way outbound only at MVP — no webhook surface to secure yet beyond the billing provider's payment webhook, which must verify its signature.

Monitoring and backups

• Daily automated Postgres backups (built into Neon/Supabase) — this is financial data, confirm point-in-time recovery is enabled, not just daily snapshots.
• Alert on reminder-send failures and bank-import parse failures — these are the two silent-failure points that directly cost the customer money if missed.

Multi-tenant by design: every distributor is an account, and every other table hangs off it.

erDiagram
  ACCOUNTS ||--o{ USERS : has
  ACCOUNTS ||--o{ BUYER_CUSTOMERS : has
  ACCOUNTS ||--o{ INVOICES : has
  ACCOUNTS ||--o{ BANK_IMPORTS : has
  ACCOUNTS ||--|| SUBSCRIPTIONS : has
  BUYER_CUSTOMERS ||--o{ INVOICES : owes
  INVOICES ||--o{ REMINDERS : triggers
  INVOICES ||--o{ PAYMENTS : settled_by
  BANK_IMPORTS ||--o{ BANK_TRANSACTIONS : contains
  BANK_TRANSACTIONS ||--o| PAYMENTS : matched_to

  ACCOUNTS {
    uuid id PK
    text company_name
    text registration_no
    text status
    timestamp created_at
  }
  USERS {
    uuid id PK
    uuid account_id FK
    text email
    text role
    timestamp created_at
  }
  BUYER_CUSTOMERS {
    uuid id PK
    uuid account_id FK
    text name
    text phone
    int credit_terms_days
  }
  INVOICES {
    uuid id PK
    uuid account_id FK
    uuid buyer_customer_id FK
    text invoice_number
    numeric amount
    date issue_date
    date due_date
    text status
  }
  REMINDERS {
    uuid id PK
    uuid invoice_id FK
    text channel
    timestamp scheduled_at
    timestamp sent_at
    text status
  }
  BANK_IMPORTS {
    uuid id PK
    uuid account_id FK
    text bank_name
    text status
    timestamp created_at
  }
  BANK_TRANSACTIONS {
    uuid id PK
    uuid import_id FK
    date txn_date
    numeric amount
    text match_status
  }
  PAYMENTS {
    uuid id PK
    uuid invoice_id FK
    uuid bank_transaction_id FK
    numeric amount
    date paid_at
  }
  SUBSCRIPTIONS {
    uuid id PK
    uuid account_id FK
    text plan
    text status
    date current_period_end
  }
    

Key constraints

• UNIQUE(account_id, invoice_number) — invoice numbers are only unique within a tenant.
• CHECK (amount > 0) on invoices, payments, bank_transactions.
• CHECK (due_date >= issue_date) on invoices.
• buyer_customers.account_id must equal invoices.account_id for any linked row — enforce via a composite foreign key or an application-layer check on write.
• Row-level security policy on every tenant table: account_id = current_setting('app.current_account_id').

API endpoints

Request/response bodies follow the entities above directly (e.g. POST /api/invoices takes {buyer_customer_id, invoice_number, amount, issue_date, due_date} and returns the created invoice with its computed status) — no separate schema needed beyond the table definitions until implementation surfaces an exception.

Sitemap

Key empty & error states

• No invoices yet: dashboard shows an import prompt, not a bare empty table.
• Nothing overdue: a plain "You're fully caught up" state — don't show an empty red bucket as if something's missing.
• CSV import fails validation: show the specific bad rows and the reason (missing due date, duplicate invoice number), not a single generic error.
• Reminder send fails (bad phone number, WhatsApp delivery error): surface it on the invoice detail page immediately, not buried in a log.
• Unmatched bank transaction with no plausible invoice: offer "ignore this transaction" so the reconciliation queue doesn't jam on unrelated bank activity.

Responsive requirements

Primarily a desktop tool for an office finance workflow — optimise the dashboard, invoice table, and reconciliation screen for desktop first. Owner-level users will check the ageing dashboard from a phone occasionally, so that one screen needs a usable mobile layout (card list instead of a wide table); the CSV import and reconciliation screens can be desktop-only at MVP.

Visual style

Minimal, professional, numbers-forward — this is a finance tool a skeptical accountant needs to trust at a glance. Tabular figures, a single calm accent color, and status conveyed by a small colored indicator (current/due soon/overdue) rather than heavy color-blocking the whole row.

Sized for one developer. The goal is a pilot customer live by week 6–8, not a finished platform.