The payout batch and the gift record, finally the same document.

What goes wrong today

The payout does not match the gift list

A Tuesday payout lands as one lump sum covering several days of giving, minus fees the processor already deducted. You match that figure back to individual donation records by hand, under a deadline, every single payout.

A refund the fundraising side never sees

Someone issues a refund straight in the payment processor. Unless they also remember to correct the donor record and the campaign total, your fundraising figures and the analytics built on them keep counting money that is already gone.

One person’s undocumented method

Your reconciliation spreadsheet works because one person has spent years learning which column means what. When that person is out, nobody else can close the month with confidence.

An audit question with no clean trail

An auditor asks where a reported figure came from. The honest answer involves several exports, a formula nobody fully remembers writing, and a promise to check later. That is not evidence, and everyone in the room knows it.

What connects, and on whose authorization

Each source below is read only after your organization configures and authorizes it.

Stripe

Charges, refunds, disputes and recurring payment events arrive with their provider reference intact, so you can trace a payout batch back to the gifts inside it.

Redsys

Spanish card gateway operations land in the same transaction model as every other provider, so a mixed-processor month still closes against one ledger.

PayPal

PayPal payments and refunds land in the same ledger as card giving, so you skip the second reconciliation process a separate processor usually demands.

Bank transfers & offline gifts Limited

Transfers and offline gifts you enter or import sit in the same record as processor activity, so the ledger does not stop at the edge of card payments. Recorded by your team or brought in by import today. Direct bank connections are on the roadmap.

CSV & spreadsheet imports

Opening balances and historical figures from a legacy system or spreadsheet join the same transaction record, so you never rebuild a closed prior period just to reference it.

The operating loop for this work

1. Connect

   Authorize the payment processors, bank transfers and import sources you already use. Nothing is read until it is configured.

2. Unify and normalize

   Charges, refunds, disputes and payout batches arrive as events and resolve into one transaction shape carrying provider reference, status and amount.

3. Reconcile

   A payout batch is read against the individual transactions it settles. A status change, refunded, disputed, failed, appears as a recorded event, not a manual note.

4. Feed analytics

   The same reconciled ledger is what fundraising analytics, AI recommendations and marketing attribution read from, so a decision upstream is never built on unverified numbers.

5. Evidence

   Every reported figure traces back to the provider events that produced it. That is the answer a treasurer or auditor actually wants when they ask where a number came from.

Why the payout figure is never the gift total

A donor gives one hundred. Less than one hundred lands in your bank account, because the processor deducts its fee before it settles the payout. Explaining that gap once is easy. Explaining it every month, for every processor, at a consistent standard, is the actual job.

Donativus records both the gross amount the donor gave and the net amount that settled, alongside the fee the processor took. A payout batch reads as the sum of the net transactions inside it. A campaign total still reports at the gross figure the donor actually gave. Neither number is a guess, and the two stop getting mistaken for each other.

This is reconciliation of data the processor already produced, not a payment operation Donativus performs. The processor still captures the charge, deducts its fee, and settles the payout. Donativus is the layer that makes that sequence legible against your own records, and trustworthy enough for the analytics built on top of it.

Refunds and disputes as recorded events, not corrections

A refund issued in the processor and a chargeback filed by a cardholder are both events that happened to a specific gift. Treat them as manual corrections someone applies later, and they are exactly the kind of thing that goes missing between the payment record and the fundraising record, quietly corrupting the analytics built from it.

Donativus ingests these as status changes on the transaction they belong to. A refunded gift shows as refunded. A disputed charge shows the dispute, then its outcome once the processor resolves it. That status travels with the transaction into every report that reads from it, so a campaign total or a donor’s giving history reflects what actually happened, not what was originally charged.

Donativus does not issue the refund or defend the dispute. Those actions happen in the processor, under your own merchant agreement. Donativus records the outcome, so your finance record never silently drifts from it.

Reading a payout batch back to the gifts inside it

A processor payout is rarely one gift. It is a batch covering a window of activity, net of fees, sometimes net of a prior refund too. Reconciling a bank deposit against fundraising activity means you can answer, for any settled amount, exactly which transactions it represents.

Because each transaction keeps its provider reference and status history, a payout batch is a defined set of transactions, not a total you match by inference. Where a processor groups several transactions into one payout, that grouping stays visible. The bank line and the transaction list are provably the same money, not probably the same money.

Closing a month without rebuilding it

The recurring failure in small finance functions is not a lack of diligence. The method for closing the month lives in one person’s spreadsheet and nowhere else. When that person is out, the close waits, or someone else does it differently, and the two months stop being comparable.

With transactions arriving already reconciled to their provider evidence, closing a month means reviewing what the ledger already shows, not assembling it from scratch. Role-aware access lets a finance lead see reconciliation detail across the organization, while other roles see only what their work requires. The method for closing the month stays the same, whoever is doing it.

What changes

Payouts you can trace

Every settled batch reads back to the individual transactions it contains, with fees accounted for.

Refunds that do not go missing

A refund or dispute recorded by the processor becomes a status on the transaction, visible everywhere that transaction is used, including analytics.

A close that does not depend on one person

The reconciled ledger is the same starting point for whoever closes the month, not one person’s undocumented method.

Figures an auditor can follow

Reported totals trace back to provider references and recorded status changes, not to a spreadsheet formula.

How it fits with what you run

• Donativus does not initiate payments, issue refunds or move money. Your processors capture, settle, refund and charge their own fees. Donativus ingests and reconciles the data they produce.
• Every source ingests only after you configure and authorize it. Donativus never connects to a bank account or a processor without that step.
• Bank transfers and offline gifts are recorded by your team or supplied through an import. Donativus does not read a bank account directly.
• Built-in analytics cover operational and fundraising reporting. Power BI is an optional, separately licensed addition for finance functions that already work in it.