Donor operations, finally connected.
Every gift, pledge and outcome—one continuous truth.
Beneora holds the whole contribution lifecycle: who gave and who is recognised, what they committed to, which bank deposit the money landed in, which restriction it satisfied, and what the organization can prove happened next.
- Tenant isolation enforced in the database
- Append-only financial audit
- Published roadmap, no certification claims
The thread above is the contribution itself. It continues into the eight obligations below — and every one of them reads the same record.
$4,812.90 deposit matched
21 gifts · $159.56 fees · 1 exception with a suggested cause
The actual problem
Your tools are fine. The gaps between them are the job.
A donation form, a processor, a CRM, a bank and an accounting package each do their part. Nobody owns the joins — so a person re-keys donors, matches a payout to a statement by hand, and answers restricted-fund questions from memory.
Every join is a person
One continuous record
Reports that disagree
Fundraising totals and finance totals diverge because one counts gifts and the other counts deposits, and no object links them.
Manual matching
A payout is a batch, a deposit is a lump sum, and refunds settle late. Reconstructing that in a spreadsheet is a monthly tax on your smallest team.
Unprovable impact
The restricted gift was spent well, but the evidence lives in a folder, a photo and an email — not attached to the gifts that funded it.
The north-star lifecycle
Eight things must stay connected. Select one.
This is the wedge we are building first, in the order value is created. Each node names the operational question it answers and the product surface that proves it — with its honest status.
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
Built for the team behind the mission
Four people share one lifecycle and never share a system.
Fundraising, finance, the executive director and the donor each need a different view of the same contribution. Pick a seat.
Development directors and gift officers
Before every conversation you rebuild context from a CRM export, an email thread and someone's memory of the last event.
What to measure: Gift-to-acknowledgment time, and first-to-second gift conversion.
One donor record that holds the whole relationship
Household, legal donor, payer and recognition are separate fields, so a business card paying for a family's gift never corrupts the relationship.
Commitments visible without a report request
Recurring plans and pledge schedules sit on the donor record, including the failures you would otherwise learn about six weeks late.
Next action rather than a dashboard
Acknowledgment owed, lapse risk and pledge follow-up arrive as assigned work with the context attached.
What connected looks like
One record per contribution, carried through every hop it has to survive.
Not a dashboard on top of five systems. The same object, extended at each step, so the deposit line and the donor's thank-you are reading from one truth.
- Gift ledger
Intent captured at checkout
Campaign, fund and restriction recorded with the payment, not reconstructed later.
- Reconciliation
A bank line you can open
Payout batch, per-gift fees and late refunds resolve to the deposit you actually received.
- Impact operations
Evidence attached to funding
Allocation, fulfillment and the stated outcome link back to the gifts that paid for it.
Five capabilities, one system
Give. Know. Commit. Reconcile. Show.
Not five products bolted together — five obligations of the same record. Each links to the pillar page with its workflow, safeguards and status.
Give
Take the gift without losing its terms
Branded forms and checkout that carry designation, restriction, recurrence, tribute and attribution into the record instead of dropping them at the payment step.
See how it worksKnow
Keep the relationship truthful
Legal donor, payer, household, recognition name and soft credits are distinct fields, so a family, a business card and a foundation grant never collapse into one confused record.
See how it worksCommit
Hold the promise, including when it breaks
Recurring plans and pledge schedules with installments, failures, retries, approved amendments and the recovery work that follows.
See how it worksReconcile
Make the money agree with the record
Transaction, fee, payout and bank deposit as linked objects, with exceptions that arrive carrying a suggested cause and an approval step.
See how it worksShow
Prove what the money did
Restrictions followed through allocation and fulfillment into an evidence chain the funding donors can actually read.
See how it worksOne gift, followed all the way
A $250 restricted recurring gift, from checkout to evidence.
This is the trace that decides whether donor operations work. Read the eight steps, then read the two surfaces that carry them.
1 · Checkout
A monthly donor gives $250 restricted to Winter Emergency Shelter. The form records the restriction, the recurrence and the attribution source, not just the amount.
2 · Donor resolution
The payment card belongs to her business; the legal donor is her household, and the recognition name is “The Okonkwo Family”. Three separate facts, three separate fields.
3 · Receipt
A versioned receipt is issued to the legal donor. A later correction produces v2 and keeps v1 readable, because a receipt is a legal artefact.
4 · Processor and fees
Gross $250.00, fee $7.55, net $242.45 — held as values on the transaction rather than derived later by a human.
5 · Payout and deposit
The transaction joins payout PO-2261, which lands as a $4,812.90 bank deposit alongside 20 other gifts. The link is an object, not an assumption.
6 · Exception
The deposit is $51.46 short. Beneora proposes a late-settling refund as the cause, shows its evidence and waits for a person to accept. Nothing posts itself.
7 · Allocation
$242.45 is allocated to the restricted fund. If someone tried to spend it elsewhere, the restriction would be the thing that objects.
8 · Evidence to the donor
The season's fulfillment — 1,914 recorded bed-nights, with the filings behind it — is published to the donors whose gifts funded it, including hers.
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
Bank side
Deposit
Jul 28 · Operating account
Statement ref
Imported from bank feed
Processor side
Payout PO-2261
21 gifts · gross $4,921.00
Fees
Card and ACH blended
1 exception · $51.46 unexplained
Suggested cause: refund RFD-119 settled in a later payout. Proposal awaits approval — nothing posts until a human accepts it.
How the software behaves
Finish the process where you are. No page hopping.
Most nonprofit software makes you leave a task to fix a missing prerequisite, then abandons you there. Beneora resolves the dependency in context and returns you to the exact step.
Right-panel work, not a new page
Creating or editing a donor, fund or pledge happens in a panel over your current context. Nested dependencies open a second layer; dialogs are reserved for destructive confirmation.
One component, many places
The same donor picker, fund selector and gift form run standalone, embedded, in a panel or as a picker — with no duplicated logic that can drift.
Outputs that state their consequences
Every completed action tells you what changed, where it appears, who can see it, which exceptions remain and what the next action is.
Monthly gift
$250
Next Aug 12 · change or pause
Pledge
50%
$3,000 of $6,000 fulfilled
Receipts
2026
Statement ready to view
What your giving did
Winter Emergency Shelter · 1,914 bed-nights recorded this season, with the evidence the organization filed.
What ships first, next and later
The roadmap is a product decision, published.
These four tiers come straight from our internal product constitution. Anything in Later is a contained prototype: it exists in the application, it is labelled, and it is not being deepened while Release 1 has open quality gates.
Now — Release 1
Must work reliably with real persistence before anything below moves up.
- Tenant isolation, authentication, roles, permissions, audit
- Organization onboarding and verification
- Branded donation forms and checkout
- Cards, wallets, ACH; one-time and recurring
- Donors, households, organizations, relationships, duplicates
+11 more in this tier
Next — Release 2
Retained in the product, but not deepened until every Release 1 quality gate passes.
- Peer-to-peer fundraising
- Events and ticketing
- Email and SMS engagement
- DAF and stock workflows
- Advanced recurring recovery
+6 more in this tier
Later — architecture-ready
Existing prototypes stay as clearly labelled demos. No new production depth.
- Global donor marketplace
- Personal crowdfunding
- Fundraising workforce marketplace
- WhatsApp and social inbox
- Advanced impact ledger
+5 more in this tier
Not planned
No new tables, pages, workflows, dependencies, integrations or polish until direction changes.
- Every social-network connector
- Global freelancer liquidity and escrow
- Tax and legal logic for many countries
- Delivery and logistics platform
- Full grant-management replacement
+5 more in this tier
Donor experience
The donor should not have to email you to change a card.
Self-service that reduces staff work instead of creating it: recurring changes, pledge visibility, retrievable receipts and the published result of a restricted gift.
- Change amount, date or payment method, or pause and cancel — each change audited on your side.
- Pledge progress the donor can see, so a reminder is a courtesy rather than a surprise.
- Receipts and year-end statements retrievable at any time, including reissued versions.
- Impact updates linked to the specific gifts that funded them, so the claim is checkable.
A donor who can answer their own question is a donor your team did not have to interrupt work for.
Monthly gift
$250
Next Aug 12 · change or pause
Pledge
50%
$3,000 of $6,000 fulfilled
Receipts
2026
Statement ready to view
What your giving did
Winter Emergency Shelter · 1,914 bed-nights recorded this season, with the evidence the organization filed.
Integrations
We connect the money path before anything else.
An integration list is a promise about someone else's system. Ours is short on purpose, and each entry carries its real status.
Payments & accounting
The money path. Built first because reconciliation depends on it.
- Designed
Card, wallet and ACH processing
Processor boundary is specified. No live money movement yet.
- Prototype
Payout and bank deposit reconciliation
The matching workspace and exception queue are the deepest prototype in the product.
- Designed
QuickBooks mapping boundary
Mapping model is specified. The connector is not built.
CRM & data
Getting your history in, and getting it back out whenever you want.
- Designed
Import, export and migration mapping
Import, export and mapped migration are specified for donors, gifts, pledges and funds. No vendor-specific sync connector is built.
- Prototype
Donor, household and recognition model
The full data model is implemented in the product against seeded records.
SMS, WhatsApp & social
Release 2. Each channel declares what it can actually do before you compose.
- Prototype
Email, SMS, WhatsApp and social channels
Release 2. Channel capabilities are declared per provider; unsupported replies are blocked.
- Paused
Donor and services marketplaces
Later-tier prototypes. Contained in the product and not marketed as shipped.
Geo & fraud
Provider-agnostic by design so no single vendor becomes load-bearing.
- Prototype
Location and community intelligence
Provider-agnostic adapters exist behind a demo provider. No paid provider is connected.
- Prototype
Governed AI proposals
Every proposal carries sources, confidence and human approval. No autonomous action.
Responsible AI
It proposes. A person decides. The decision is logged.
AI is useful here for exactly one thing: finding the explanation a human would have spent forty minutes reconstructing. It never moves money, never edits a receipt and never writes to a donor on its own.
Sources attached
Each proposal lists the records it read — the payout, the refund, the statement line — so you can check the reasoning instead of trusting it.
Confidence stated
A numeric confidence value, plus the threshold above which the proposal may be auto-suggested and below which it stays quiet.
Approval required
Posting, matching and donor-visible changes require explicit human acceptance, recorded with who accepted and when.
No training on your data
Tenant and donor data is not used to train models by default, and donor PII is not exposed to model context for convenience.
Trust mechanisms
Mechanisms and limits, not badges.
Each item below states how it works and where it stops. When a formal audit starts, this page will name the framework, the auditor and the date.
Tenant isolation
Every read, write, cache key and background job carries the tenant and active scope. Database row-level security enforces it at the data layer rather than in application code alone.
Limit: Under active hardening as part of Release 1. Isolation is verified by test, not by a third-party audit.
Auditable actions
Financial, receipt, posted and verified states are server-enforced and append-only. Edits add events; they do not overwrite history.
Limit: Prototype modules record audit events against illustrative data until persistence lands.
Human approval on money and AI
Proposals carry sources, confidence, effect and cost. Posting, matching and donor-visible changes require a person to accept them.
Limit: No autonomous financial action exists, and none is planned for Release 1 or Release 2.
Data portability
Donors, gifts, pledges, funds and reconciliation records are exportable in full. Your data is not a retention mechanism.
Limit: Export coverage grows with each module that reaches real persistence.
Encryption in transit and at rest
All traffic is served over TLS, and managed Postgres storage plus backups are encrypted at rest by the hosting provider.
Limit: Standard managed-platform encryption. We do not claim customer-managed keys.
No certification claims
We publish mechanisms and programme status instead of badges. When a formal audit begins, this page will name the framework, the auditor and the date.
Limit: Beneora holds no SOC 2, ISO 27001, PCI or HIPAA attestation today.
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.
Direct answers