Reconcile Donations With Your Accounting System
Goal: Build one monthly donation report that carries the Class, the account, and the gross/fee/net split your bookkeeper needs, so month-end close is a single export instead of a hunt through the payment processor.
Why the default columns aren't enough
The stock donation columns answer "how much did we raise?" They don't answer "what do I type into QuickBooks?" — which needs the Class, the income account, and the difference between what the donor was charged and what actually reached the bank.
Those columns now exist in the report builder. Add them once, save the report, and re-run it every month.
The money columns, and which one is "gross"
Three different numbers are involved in a single online gift, and they are genuinely different amounts:
| Column | What it is | Example |
|---|---|---|
| Gift Amount (Revenue) | The donor's intended gift — the contribution revenue you recognize | $100.00 |
| Gross Amount (Charged) | What the donor's card or bank account was actually charged | $104.25 |
| Processing Fee | What the processor actually assessed on the charge, once the settlement that paid it out has been synced; until then, the fee estimate booked when the gift was charged. The Fee Basis column says which one a row is showing | $4.25 |
| Fee Basis | actual once the settlement has recorded the processor's fee, estimate for a card or ACH gift whose settlement has not synced yet, none for a hand-recorded gift that never touched the processor | actual |
| Net Deposit | The charge less the processing fee: what landed in your bank account for this gift once the fee is actual, what is expected to while it is an estimate | $100.00 |
That example is a gift where the donor covered the fee: they chose to pay $104.25 so the affiliate would receive the full $100.
When your affiliate absorbs the fee instead, the same $100 gift looks like this:
| Column | Value |
|---|---|
| Gift Amount (Revenue) | $100.00 |
| Gross Amount (Charged) | $100.00 |
| Processing Fee | $4.25 |
| Net Deposit | $95.75 |
Add the Donor Covered Fees column when you want to see at a glance which rule applied to a given gift.
:::tip Which column do I book as revenue? Omnivo's own journal entries credit Gross Amount (Charged) to income when the donor covers the fee, and book the processing fee as an expense: everything the donor paid is their contribution (their receipt already says so), and the fee is what it cost you to receive it. Sponsorship payments and pledge installments paid online with the fee covered book the same way (a pledge installment still reduces Pledges Receivable by the installment amount, with the covered fee credited to income). That is the treatment most nonprofit bookkeeping guidance recommends, and it keeps a refund clean, because the refund reverses exactly what was booked. If your firm prefers to book the donor's intended gift as revenue and treat the covered fee as a wash, use Gift Amount (Revenue) and reclassify the fee lines in your accounting system. Pick one and stay with it; the report gives you both so you don't have to rebuild it if the policy changes. :::
Two more columns round out the picture:
- Refunded Amount — what has been refunded against the gift.
- Cash, check, and other hand-recorded gifts never touch the payment processor, so their Processing Fee is always $0 and gross, revenue and net are all the same number. This matches how those gifts post to your general ledger.
Settlement true-up
Every charge books its processing fee at the estimate, because that is all anyone knows when a card is charged. The fee the processor actually assesses depends on the card and on your affiliate's pricing model, and it is final only when the processor closes the settlement batch that pays the charge out.
Omnivo closes that gap per batch. When a settlement closes, it pulls every fee the processor assessed on the batch, ties them to the batch total, and shows the batch on Accounting → Payment Reconciliation under Processor Fees by Settlement: the gross, the actual fees, the estimates that were booked, the variance and a Tied badge when the fees reconcile. Opening a batch lists every charge with its estimate beside its actual.
If the batch's actual fees differ from the estimates booked, Omnivo posts one Settlement True-up journal entry for the batch: fee expense up and cash down when the processor kept more than the estimates, the reverse when it kept less. The entry uses your default mapping's fee expense and deposit accounts and is linked from the batch's True-up column. After it, the cash lines for the batch sum to the amount the processor deposited, so the deposit on your bank statement ties to the ledger. A batch whose fees equal the estimates posts nothing and shows a zero true-up.
Three things to know:
- On flat pricing the true-up is usually zero or a few cents. A batch with card-present sales can be off by up to a cent per sale, because the processor rounds the batch's fees once while each sale's estimate is rounded on its own. A fee with no estimate behind it, such as a dispute fee or an ACH return fee, shows up in full. The true-up moves more once your affiliate is priced on interchange plus.
- A batch marked Mismatch did not tie (the fee rows did not sum to the processor's total, or a member charge is missing); use Re-sync fees from Finix on the row, and contact support if it stays red.
- The true-up entry is a draft like every other generated entry. Review it with the rest of the period's entries. Once it is synced to your accounting system it is never altered: if the batch later comes to true up to a different figure (a fee the processor added after the first sync, a charge recorded late), Omnivo posts a separate correcting true-up draft for the difference only, dated the batch cut and naming the entry it corrects, and retires that draft again if the figures return to what was synced. The batch's True-up column shows the total its entries carry; the link opens the first entry, and the correction sits beside it under the same source filter.
Settlement records
The same page keeps one record per settlement batch under Reconciliation
Records, and Run Reconciliation builds or refreshes the records for a
date range. A record compares what Omnivo expected the batch to carry against
the batch's total at the processor. Expected is every transfer in the batch
that Omnivo can match to one of its own records: the register's sales and
refunds, and the online charges (donations, recurring gifts, pledge
installments, sponsorship payments, event registrations and pickup charges),
each matched by its transfer id. The counts column shows what matched, for
example 0s / 0r / 12 online.
- Completed means the batch matched records and the expected amount is within a cent of the batch total.
- Discrepancy means it matched records and the two differ. Open the record: it lists the register transactions, the online charges by source, and any member of the batch Omnivo could not match. A refund of an online gift and a dispute debit land in that last list, because Omnivo does not yet record which reversal paid them. Their amounts explain the variance.
- Pending means nothing in the batch matched an Omnivo record, so no check was performed, for example a batch that settled before its charges were recorded.
- Reviewed means someone resolved the discrepancy with a note. The record stays reviewed when the batch is refreshed with the same variance; it returns to Discrepancy if the variance changes, and reads Completed once the batch reconciles.
A record is refreshed each time its batch settles and each time you run the reconciliation again, so a batch flagged before online charges counted reads correctly after one more run.
Export a settlement
Open a record, or a batch under Processor Fees by Settlement, and use Export this settlement to download the batch as a PDF or a CSV. Either one lists every transaction the batch paid out for your affiliate, one row each: the date, who paid and their email, what it was for (the donation's campaign, the pledge installment, the sponsorship package, the event, the pickup, or the store and sale number), the fund and designation, the general ledger account and class the transaction books to, the processor's transfer id, the amount, the processing fee and the net. The header carries the batch's own gross, fees, net and deposit date, and the last row is the total, so the page can be read against the bank deposit and filed with it.
The fee on each row is the fee the processor actually assessed once the batch's fees have synced, and the estimate booked at the charge, marked "est.", before that. The fee total is the processor's own rounding of the batch, so it ties to the batch; the row fees are rounded one by one and can differ from that total by a cent. The GL columns read the transaction's journal entry when it has one and say whether it is booked; a transaction not yet booked shows the account its entry will book through, so run Generate Entries first if you want the export to carry the posted codes. A member of the batch that Omnivo could not match is listed separately with its amount.
The accounting columns
| Column | What it shows |
|---|---|
| GL Class | The Class the gift maps to in your accounting system |
| GL Income Account | The income (revenue) account the gift maps to |
| Fund / Fund Code | The named fund the gift is assigned to |
| Designation Type | Whether the gift was designated to a campaign, project, event, fund, or general use |
| Restriction | Unrestricted, temporarily restricted, or permanently restricted |
GL Class and GL Income Account come from your account mappings — the same mappings Omnivo uses when it builds journal entries, so the report and your posted entries agree. Set them up under Administration → Accounting → Account Mappings. A gift uses the most specific mapping that applies to it: an exact match on its designation wins over a designation default, which wins over your organization-wide default.
If a gift shows a blank Class, either no mapping matches it or the matching mapping has no Class set. Fix it in Account Mappings and re-run the report — nothing needs to be re-entered on the donation itself.
When a gift is assigned to a fund and no mapping specifies a Class, the report falls back to the Class set on the fund itself (Administration → Accounting → Funds).
Build the report
- Go to Reports → Custom and click New Report (or open your existing Donation Summary and click Edit).
- Set the data source to Donations.
- Add the columns you need. A working month-end set:
- Donation Date
- Deposit Date
- Receipt Number
- Donor First Name / Donor Last Name
- GL Class
- GL Income Account
- Fund
- Gift Amount (Revenue)
- Gross Amount (Charged)
- Processing Fee
- Net Deposit
- Add a date filter for the month you're closing — on Deposit Date if you reconcile to your bank, on Donation Date if you reconcile to when gifts were given. See Closing on the deposit date.
- On Sort & Group, group by GL Class and add a Sum of Gross Amount (Charged) and Net Deposit for a one-line-per-Class summary.
- Save the report so next month is one click.
Every one of these columns can also be filtered and sorted, so you can pull a single Class or a single fund when you're chasing a difference.
Export it
From the report's view, click Export:
- Excel or CSV for the data table your bookkeeper works from.
- PDF for the formatted version with totals and branding.
Register round-ups and checkout donations
Gifts taken at the ReStore register — a customer rounding a sale up, or adding a donation at checkout — are donations like any other and post through the same donation journal entry, but the books can tell them apart. The entry's memo names the kind and the sale (Register round-up donation on sale T-1001, Register checkout donation on sale T-1001), and the revenue line reads Round-up donation revenue or Checkout donation revenue rather than the generic donation line.
If you want them on separate income accounts, each account mapping has two optional fields under Accounting → Account Mappings: Round-up Donation Income and Checkout Donation Income. Set one and that kind credits it; leave it blank and the kind credits the mapping's regular income account, as it always has. Entries already posted keep the account they posted to — to move them, void and regenerate, as with any other account change.
Exporting the journal entries themselves
The report above is the donation-level view. If what you actually hand your accounting software is the posted entries, export those directly from Accounting → Journal Entries, where Export offers two files:
- Detailed CSV — one row per journal entry line, with the account, class, amount and description on each. This is the file you import.
- Summary CSV — one row per entry with its debit and credit totals, sync status and any sync error. Useful for spotting an entry that never made it across.
Both files end with a Party Name column: the individual or organization whose money the entry represents. It is filled in for every kind of payment.
Where an organization is on the record, the organization is named rather than the person who happened to place the transaction — a law firm that sponsors a table is the payer, not the assistant who filled in the form. Otherwise the linked constituent is named, and failing that, whatever name the record itself carries.
| Entry source | Whose name appears |
|---|---|
| Donation, and its refund reversal | The donor |
| Pledge, and each installment against it | The donor on the pledge |
| Sponsorship payment or refund | The sponsor |
| Event registration or refund | The purchaser, not the attendee |
| In-kind donation | The donor |
| ReStore sale or refund | The customer, when the sale was rung up against one |
Two things worth knowing about how names are chosen:
- Event registrations name the purchaser. One person often buys a table of ten and types in nine other people's names. The purchaser is the one whose money you received, so that is the name on the entry.
- An anonymous gift still names its donor. Marking a gift anonymous keeps the donor off your public lists; it does not mean you don't know who gave. This export is an internal accounting document that has to reconcile to a bank deposit and support your substantiation, so a donor on file is named. A gift that is both flagged anonymous and never linked to anyone reads "Anonymous".
The column is blank in three situations, all of them correct:
- A walk-in ReStore shopper. Most counter sales are genuinely anonymous.
- A manual adjustment or a year-end closing entry. There is no counterparty; inventing one would be worse than leaving it empty.
- A sponsorship benefit delivery. These record the fair market value of a benefit against a sponsorship package, which more than one sponsor can hold, so the entry cannot be traced to a single company. The entry's memo names whoever the delivery was recorded under.
The column is worked out fresh at export time from the underlying record, so it appears on entries you posted months ago, and a party you rename or merge later exports under the new name.
The entry's Memo names the payer too — "Donation from Joseph Brown", "Event registration from Acme Manufacturing — Spring Gala". Unlike the column, the memo is written once when the entry is created, so registrations posted before this went in keep their older wording. The Party Name column is the one to sort and map on.
Closing on the deposit date
Two different dates matter, and for card and ACH gifts they are usually different days:
| Column | What it means |
|---|---|
| Donation Date | When the gift was made |
| Deposit Date | When that money reached your bank account |
A gift made on the last day of the month is very often deposited in the following month. If your accounting system is keyed to the deposit date — as QuickBooks usually is — closing on the donation date will disagree with it at every month boundary, by exactly the gifts caught in that gap.
To close on the deposit date instead:
- Add the Deposit Date column to your report.
- Set your date filter on Deposit Date rather than Donation Date.
Now "everything deposited in August" is what you get, which is what your bank statement and your accounting system both show. You can also group by Deposit Date to roll a month up the same way.
Both dates are plain calendar days
Donation Date and Deposit Date are both plain dates — 2026-08-31, with no time
of day. They export as real dates, so Excel and Google Sheets sort and filter
them rather than treating them as text.
Each day is worked out in your affiliate's own time zone, and that is what keeps a late-evening gift or payout in the right month. A gift made at 8:15 PM on August 31 is an August gift for an affiliate on Eastern time, even though the clock has already rolled over to September 1 in UTC. The same goes for a payout your processor sends that evening.
Your time zone is set under Administration → Affiliate Management. If it is wrong, gifts and deposits near midnight will land on the wrong day — and at a month end, in the wrong month.
When Deposit Date is blank
- Cash, check, and other hand-recorded gifts never go through the payment processor, so there is no deposit to date. Reconcile those against your own deposit slips.
- Recent gifts whose payout hasn't been sent yet. The date appears once the money moves — usually a business day or so after the gift.
- Gifts from before deposit tracking was switched on. An administrator can backfill these from Accounting → Reconciliation, which replays your settlement history from the payment processor.
A blank Deposit Date always means "not known yet". Omnivo will not put an estimated date in that column — a deposit date that is quietly a day or two off is worse than a missing one, because it looks right.
:::note What "deposited" means The Deposit Date is when your payment processor sent the payout to your bank on the ACH network. Depending on your bank, the funds may post a day or more after that. If your accounting system keys off the date the money appears on your bank statement, check one payout against a statement first to see whether your bank posts same-day. :::
Sponsorship and event registration revenue
Sponsorship payments and event ticket sales are not donations, so they never appear in the Donations data source — even though their card payments land in the same bank deposits. If you close the month on the deposit date, you need them too, or the report will come up short of your bank statement by exactly that money.
Each has its own data source in the report builder:
| Data source | One row per | Who can use it |
|---|---|---|
| Sponsorship Payments | Sponsorship installment, paid or scheduled | Anyone who can view sponsorship payments |
| Event Registration Payments | Ticket purchase (one row covers every attendee on the order) | Anyone who can view event registrations |
Both carry the same month-end columns as Donations: Deposit Date, Processing Fee, Net Deposit, Fund and Fund Code. Deposit Date works exactly as described above — your affiliate's own calendar day, blank for checks and cash, and blank until the payout is sent.
The other columns differ a little, because the payments themselves do:
- Sponsorship Payments has Scheduled Amount (what the installment was due to be), Payment Amount (Revenue) (what the sponsor paid), and Gross Amount (Charged) (what their card was charged, including the fee if they chose to cover it). It also shows the Sponsor, Package, what was sponsored, the Paid Date, and the invoice and receipt numbers. An installment that hasn't been paid yet shows its Scheduled Amount and $0 in every other money column.
- Event Registration Payments has Amount Charged (Revenue) — the full amount charged for the tickets, which is what Omnivo books as event revenue — and Refunded Amount. It shows the Event, the purchaser (not each attendee), the purchasing organization, the number of Attendees on the order, and the Payment Date.
To close a month across everything that hit the bank, build the same report on each of the three data sources — Donations, Sponsorship Payments, Event Registration Payments — each filtered on Deposit Date for the month, and add the three Net Deposit totals together.
:::note The date range at the top of a report When you run a report, the date range at the top of the page applies to the Paid Date on Sponsorship Payments and the Payment Date on Event Registration Payments. Set it wide enough to cover your Deposit Date filter — a payment made on the 31st is often deposited on the 1st. :::