Why Zetu
Billing tells you what you asked for. Payments tell you what arrived. Zetu connects the two.
- 01
What should have been received?
ExpectedEXPECTED$84,200100.0%Every obligation that came due this period, from every agreement.
- 02
What actually came in?
ReceivedRECEIVED$79,10093.9%All money that landed, on every rail, including money nobody asked for yet.
- 03
What have we confidently connected to an obligation?
AllocatedALLOCATED$77,60092.2%Matched to a specific obligation on a specific account, with the rule that matched it recorded.
- 04
What still needs investigation?
UnallocatedSUSPENSE$1,5001.8%9 payments held in suspense. Real money, in the bank, not yet attached to anything.
- 05
What remains collectible?
OutstandingOUTSTANDING$5,1006.1%47 accounts. This is the number that becomes the collections worklist.
The divide
Recurring revenue has two realities.
What should happen
Someone owes an organization something, for a reason, by a date. This is knowable in advance, it is the same every period, and it is the denominator for every figure a finance team reports.
What actually happens
Money arrives late, partially, twice, through a different channel, under a different name, without a reference, from someone else — or not at all.
Most software owns one side of that divide cleanly. Billing platforms and membership systems live on the left. Payment providers live on the right. Accounting systems record whatever crossed over, afterwards.
The join between them is where organizations lose control of their money, and it is almost always staffed by a person with a spreadsheet.
The categories
What each category is genuinely good at — and where it stops.
| Category | What it is genuinely good at | Where it stops | What Zetu adds |
|---|---|---|---|
| Subscription billing | Plans, subscriptions, metered usage, card-on-file charging, dunning and revenue recovery. Excellent at recurring revenue that arrives on stored cards. | Assumes a self-identifying payment instrument. Payments arriving without a reference, from a third party, or on a rail with no payer identity are outside the model. | Obligation-first billing across heterogeneous rails, with reconciliation and payer identification as core capabilities rather than edge cases. |
| Accounting & ERP | Ledgers, statutory reporting, tax, audit and the general financial record. The system of truth for what happened, after it happened. | Records financial history rather than operating it. Cash application, exception queues, collections workflow and account standing sit outside its remit. | Operates the relationship in between — and posts the result to accounting rather than competing with it. |
| Membership management | Member databases, events, renewals, directories, email and community — and a member portal for all of it. Strong on the experience of belonging to an organization. | Financial depth is usually shallow: one balance per member, limited reconciliation, no cash application, no collections operation. | Financial control over member money — multi-rail reconciliation, obligations, standing and collections — plus the member's own view of that record, showing which obligations each payment settled rather than a single balance. Coexists with a community platform; it is not trying to be one. |
| Payment providers | Moving money reliably and at scale, across cards, mobile money, bank rails and wallets. Settlement, security and reach. | A provider knows a transaction succeeded. It does not know what the money was for, whose obligation it settles, or what should happen next. | Understands what the money meant. Keep your providers; Zetu turns their transactions into settled obligations and changed standing. |
| Spreadsheets | Honestly, quite a lot. Infinitely flexible, immediately available, and they encode the exceptions the real system could not. | No audit trail, no concurrency, no continuity when the person leaves, and no way to know when a formula stopped being right. | The exceptions become first-class objects with owners and outcomes, so the spreadsheet stops being load-bearing. |
Zetu does not need to be the right tool for every organization. If your revenue is card subscriptions with sophisticated usage pricing, a subscription billing platform will serve you better and we would rather tell you that in the first conversation than in the sixth month.
Payment tells you money arrived. Zetu tells you what it meant.
$100 was received from this payer, was intended for these obligations, leaves this balance outstanding, changes this account's standing, and requires this next action.
Every clause in that sentence requires something the transaction itself does not carry: a payer record, a set of obligations, an allocation, a standing policy and a workflow. That is what Zetu is.
Differentiation
Eight things that are not commodity features.
Obligation-first, not payment-first
Zetu starts from what should happen and compares it to what did. Payment systems start from a transaction; subscription systems from a plan; accounting from an invoice.
Reconciliation is core, not an afterthought
What was expected, what was received, where it came from, who sent it, which obligation it settles, and what remains unmatched — as a first-class capability with its own queue.
Payment rail independence
Mobile money, bank, card, gateway, direct debit, cash — on whichever rails your market runs on. All of it terminates in the same financial model, so changing a provider, or a country, changes nothing downstream.
Real-world payer relationships
Payer, account holder and beneficiary as separate records. A parent paying for three children and a company paying for twenty-five staff are the normal case.
Exception-first operations
Traditional systems optimize the happy path. Finance teams live in the exceptions, so Zetu makes them visible, owned and actionable.
Collections as an operation
Aging, worklists, assignment, promises, arrangements, disputes, escalation and outcomes — not an increasingly firm sequence of emails.
Independent financial truth
Where a second source exists, Zetu compares rather than trusting whichever system spoke last. Mismatches are findings with a value attached.
Standing and entitlement
What a balance means for the relationship, and what it switches on or off in the real world — governed by your policy, not hard-coded.
There is genuine scope for models to help with several of these — ranking collectible accounts, proposing likely matches, summarizing an account history, spotting anomalies. None of it is the category, and we are not going to describe Zetu as AI-powered as though that were the argument.
Category comparisons
In more detail.
Zetu vs subscription billing
Where plan-and-card billing ends and receivables operations begin.
Read the comparisonZetu vs accounting software
Recording financial history versus operating the relationship.
Read the comparisonZetu vs membership software
Member databases versus financial control over member money.
Read the comparisonThe category
The financial infrastructure behind recurring relationships.
Who
has a financial relationship with the organization, and in what capacity.
Why
they owe something — the relationship and the policy that make the obligation legitimate.
What and when
they are expected to pay, on which schedule, under which terms.
What arrived
in fact, on which rail, from whom, and whether it is what the provider claims.
Where it belongs
which obligation each payment settles, and how confidently.
What remains
outstanding, how old it is, and whether it is genuinely collectible.
What that means
for this account's standing, given the arrangements and exceptions on it.
What happens next
who acts, on what, and what they committed to.
And eventually
what the person remains entitled to as a result.
No existing category answers all nine. That gap is the category, and it is why Zetu exists.
Questions
The ones buyers actually ask
Is Zetu trying to replace our accounting system?
No. Accounting records financial history for statutory and reporting purposes, and it should keep doing that. Zetu operates the financial relationship day to day — obligations, settlements, standing, collections — and posts to accounting. The two have different jobs, different users and different update frequencies, and organizations that try to run receivables operations inside a general ledger generally end up with a spreadsheet anyway.
When is Zetu the wrong choice?
If nearly all your revenue arrives on stored cards against clean subscription plans, and your hard problems are metered usage pricing, global tax, revenue recognition and failed-card recovery, then a subscription billing platform is a better fit and we will say so. Zetu's advantage appears where money arrives on several rails with weak reference data, where payer and beneficiary diverge, and where reconciliation and collections consume real staff time.
Do we have to change our payment providers?
No. Zetu does not move money and has no interest in becoming a gateway. Keep the providers and bank relationships you already have — Zetu sits behind them and turns their transactions into settled obligations and updated standing.
Is this just an accounts receivable module?
AR modules are built around invoices and ledgers, which means they inherit the assumption that an invoice is the record of what is owed. Zetu is built around obligations, which exist independently of documents, and around the operational work — matching, exceptions, worklists, promises, standing — that AR modules leave to a person and a spreadsheet.
Keep reading
- ReconciliationThe clearest demonstration of the difference.
- CollectionsThe other half of the operational argument.
- About ZetuThe thesis, and where it came from.
- Recurring billing vs recurring receivablesThe distinction in one article.
- PricingHow Zetu is priced, and what it will not charge for.
- SecurityHow the financial record is protected.
Bring us one messy month.
Bring one month of obligations and one month of payments. We will show you what reconciles, what does not, and what that is costing you.