One ledger for dues and event revenue
Dues invoices and event revenue land on the same 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.
Payment rails built for where chambers actually operate
Stripe covers most Western card processing; TapPay, JKoPay, and LinePay cover Taiwan and broader APAC payment methods that a Stripe-only tool simply can't take. A bilateral or bi-national chamber running dues in more than one region needs this, 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.