Platform overview
One lifecycle, held by one system
Beneora is not a suite of modules that happen to share a login. It is one record moving through eight obligations — and the whole product exists to keep that movement traceable.
Beneora is being built with a small group of US and Canadian nonprofits. Product surfaces you see on this site exist in the application; the status label on each one tells you whether it runs on real data yet.
Gift received
Recurring · Winter Shelter (restricted)
Processor fee
2.9% + $0.30 · card
Net to payout
Payout PO-2261 · settles T+2
Bank deposit
Matched batch of 21 gifts
Fund allocation
Winter Shelter · restriction honoured
The lifecycle
Select a step to see what it must hold
Each node names the operational question, the objects involved and the product surface that carries it.
Gift
Prototype: Interactive in the product with illustrative data. Not persisted, not production ready.Amount, designation, restriction, one-time or recurring, tribute, source and attribution.
Gift received
Recurring · Winter Shelter (restricted)
Processor fee
2.9% + $0.30 · card
Net to payout
Payout PO-2261 · settles T+2
Bank deposit
Matched batch of 21 gifts
Fund allocation
Winter Shelter · restriction honoured
Why one system
Every step above is the same record, not a copy of it
Most stacks lose the connection at the handoffs: the form does not know the deposit, the deposit does not know the restriction, the restriction does not know the donor who reads the result. Beneora keeps one record and lets each desk read it.
- 01 · Capture
Terms recorded with the payment
Designation, restriction, recurrence and attribution are fields on the gift, not notes added afterwards.
- 02 · Recognise
Legal donor stays separate from credit
Payer, legal donor, household and soft credit are distinct, so recognition never rewrites the receipt.
- 03 · Settle
Payout resolves to a bank line
Fees, refunds and late disputes are carried on the same object the deposit is matched against.
- 04 · Allocate
Restriction survives the transfer
The restricted balance is derived from gifts and allocations, not maintained by hand in a second place.
- 05 · Prove
Evidence points back at funding
Fulfillment and the stated outcome link to the specific gifts that paid for them, and the donor reads the same link.
Gift received
Recurring · Winter Shelter (restricted)
Processor fee
2.9% + $0.30 · card
Net to payout
Payout PO-2261 · settles T+2
Bank deposit
Matched batch of 21 gifts
Fund allocation
Winter Shelter · restriction honoured
Seven pillar pages
Read the pillar that matches your problem
Giving & payments
PrototypeTake the gift without losing its terms
Did everything the donor told us survive the payment step?
Read the pillarDonor relationships
PrototypeKeep the relationship truthful
Who actually gave, who gets credit, and who do we thank?
Read the pillarPledges & recurring
PrototypeHold the promise, including when it breaks
What was promised, what has arrived, and what is quietly failing?
Read the pillarReconciliation
PrototypeMake the money agree with the record
Does the bank statement agree with the gift ledger, and if not, exactly why?
Read the pillarImpact & reporting
PrototypeProve what the money did
Which gifts funded this result, and can we show the evidence?
Read the pillarDonor experience
PrototypeThe donor should not have to email you
Can a donor answer their own question without creating staff work?
Read the pillarIntegrations
DesignedThe money path first. Everything else later, and labelled.
Which systems must agree with Beneora for the numbers to be trustworthy?
Read the pillarStatus, in one table
Every capability we are willing to talk about
This table is the source of truth for status labels across the whole website. If a page implies more than this table says, the page is wrong.
Built is not working. Working is not verified. Only the table below decides what we claim.
| Capability | Status | What that means here |
|---|---|---|
| Accounts, roles and tenant isolation | Active build | Accounts, profiles, roles and organization records persist. Scoping rules are being hardened. |
| Branded donation forms and checkout | Prototype | Form builder and donor checkout are interactive with illustrative data. |
| Cards, wallets and ACH processing | Designed | Processor boundary is specified. No live money movement yet. |
| Donors, households, recognition and soft credits | Prototype | The full data model is implemented in the product against seeded records. |
| Pledges, installments and recurring recovery | Prototype | Lifecycles, amendments and failure paths are modelled and navigable. |
| Receipts and year-end statements | Prototype | Versioning and audit behaviour modelled. Not a tax-compliance guarantee. |
| Transaction → fee → payout → deposit reconciliation | Prototype | The matching workspace and exception queue are the deepest prototype in the product. |
| Funds, designations and restrictions | Prototype | Restriction tracking and allocation are modelled end to end. |
| Fulfillment and impact evidence | Prototype | Evidence chain links gifts to recorded outcomes with an immutable trail. |
| Donor self-service portal | Prototype | Giving history, recurring management, pledges and receipts are navigable. |
| QuickBooks integration boundary | Designed | Mapping model is specified. The connector is not built. |
| Governed AI proposals | Prototype | Every proposal carries sources, confidence and human approval. No autonomous action. |
| Email, SMS and social channels | Prototype | Release 2. Channel capabilities are declared per provider; unsupported replies are blocked. |
| CRM and data exchange | Designed | Import, export and mapped migration are specified for donors, gifts, pledges and funds. No vendor-specific sync connector is built. |
| Geo intelligence and fraud signals | Prototype | Provider-agnostic adapters exist behind a demo provider. No paid provider is connected. |
| Donor marketplace and services marketplace | Paused | Later-tier prototypes. Contained in the product and not marketed as shipped. |
- Research
- We are studying the workflow with design partners. Nothing is built.
- Designed
- The workflow is specified and drawn. Implementation has not started.
- Prototype
- Interactive in the product with illustrative data. Not persisted, not production ready.
- Active build
- Being implemented now against real persistence and permissions.
- Beta
- Running with design partners on real data, with known gaps.
- Available
- Persisted, permissioned, error-handled and verified end to end.
- Paused
- Deliberately not being worked on while Release 1 quality gates are open.
Direct answers
What visitors ask about the platform
- What is Beneora?
Beneora is donor-operations software for US and Canadian nonprofits with roughly two to thirty fundraising, finance and operations users. It carries one lifecycle: a gift arrives, the right donor and recognition are recorded, a receipt is issued, the payout is reconciled to the bank deposit, the fund restriction holds, and the donor sees the result.
Read the lifecycle- Who is the legal donor, the payer and the recognition name?
The legal donor is the party entitled to the receipt. The payer is whoever the money came from, which can be a card, a household member, a donor-advised fund or an employer. The recognition name is how the gift is credited publicly. Beneora records all three separately, so a receipt is never wrong to make a listing right.
See donor relationships- What is the difference between a payout and a deposit?
A payout is the batch a payment processor sends after fees are deducted. A deposit is the line your bank actually shows. Reconciliation means matching gross gifts, processor fees and net payout to that deposit line, then explaining every exception. Beneora treats the unmatched exception as the working surface, not an error state.
See reconciliation- Is Beneora available today?
Parts of it. The status table on this page is the only claim we make: Available, Active build, Prototype, Designed, Research and Paused are distinct statuses, and no page overrides them. If a capability is not marked Available, treat it as work in progress and ask us where it stands.
See the roadmap
Design-partner program
Build the donor-operations layer with us
We are working with a small number of US and Canadian nonprofits who feel the reconciliation and donor-data pain most acutely. Partners shape the sequence, see the honest status of every module, and are never charged for a capability that is still a prototype.