Invoicing on a real ledger, and a bank statement matched to the right member by payer.
Dues invoices and event ticket payments on one payment ledger, backed by Postgres, not a spreadsheet or localStorage demo
Two real payment rails, Newebpay for Taiwan and Stripe worldwide, each with a hosted checkout that settles to the chamber's own account
Bank-statement reconciliation that reads a Taiwanese statement and proposes which member each payment belongs to, for a person to confirm
Accounts-receivable aging and overdue-invoice visibility in one place
In the productFinancePayment accounts
One ledger for dues and event payments
Dues invoices and event ticket payments land on the same payment ledger, backed by a real Postgres payments layer rather than the deterministic demo data most of the rest of the product runs on for the pitch build. That distinction matters if you're evaluating this seriously: the finance numbers you'd see in a pilot are the real payment records, not seed data. A ticket paid at registration gets a numbered receipt rather than an invoice.
Payment rails built for where chambers actually operate
Stripe covers card processing in its supported countries; Newebpay covers Taiwan, where Stripe cannot pay out at all, on Newebpay's own hosted payment page. Which methods that page offers depends on what the chamber's Newebpay account has switched on. A bilateral or bi-national chamber running dues in more than one region needs both, not as a nice-to-have but because the alternative is manually reconciling wire transfers.
The reconciliation problem nobody else solves for Taiwan
A Taiwanese bank statement does not tell you who paid you. Members pay by ATM transfer and the statement shows the last five digits of the sending account, not a company name, so a chamber treasurer spends the end of every month matching a column of five-digit codes against a members list by hand.
Upload the statement and the finance workspace parses it, reads those payer codes and names, and proposes which member and which open invoice each line belongs to, ranked by confidence. Where two members are a genuinely close match it refuses to guess and asks. Nothing is written until a person confirms it, and confirming is one click per line.
To be clear about what this is not: there is no accounting-package integration in this build. Your accountant keeps their own system of record, and reconciliation here means the chamber's own ledger reflects the bank, confirmed by a human rather than assumed.
Frequently asked questions
What payment methods does Chamberflow actually support?
Stripe (cards, in the countries Stripe supports) and Newebpay (Taiwan; the methods on its payment page are the ones the chamber's Newebpay account offers). Which one is active depends on which account a chamber connects under Payment accounts settings. If both are connected, online payments go through Stripe. Bank transfer with manual confirmation is always available.
Does Chamberflow integrate with QuickBooks or Xero?
No. There is no accounting-package integration in this build, and the product says so in the reconciliation panel itself rather than implying otherwise. What it does instead is reconcile the chamber's own ledger against an uploaded bank statement, with a person confirming each match.
How does it know which member sent an ATM transfer?
It matches on what a Taiwanese statement actually carries: the last five digits of the sending account, the payer name where one is present, the amount, and the open invoices for that member. It proposes a match and a person confirms it. Where two members are too close to separate, it declines to choose rather than booking the payment to the wrong one.
See the Member CRM, Dues, and Events working together
Book a demo: we'll run it live in a working demo workspace, not a slide deck.