Gift date vs. entry date vs. batch date: why your fiscal totals never reconcile

A gift carries at least three dates, and they are not interchangeable. Gift date is when the donor gave. Entry date is when a staffer keyed it. Batch date is when it posted in a batch. Use one where you meant another (which most shops do without noticing) and your fiscal-year totals won’t reconcile, your “last gift date” will be wrong, and year-end giving will appear to slip into January.

Why don’t my fiscal year totals reconcile?

Almost always because revenue is being attributed by when it was processed rather than when it was given. A check dated December 28 that gets keyed on January 3 belongs to December’s fiscal year by gift date, but if your report keys off entry date, it silently jumps into the next year. Multiply that by every gift that crosses your fiscal boundary, and the totals from two different reports will never agree.

The three dates

| Date | What it marks | Who cares | |---|---|---| | Gift date | when the donor actually gave (check date, charge date) | revenue, fiscal totals, “last gift” | | Entry date | when staff keyed the record | data-entry throughput, audit trail | | Batch date | when the gift posted in a processing batch | finance reconciliation, deposits |

All three are correct facts about the same gift. The error isn’t recording them. It’s using whichever one is handy as if it were “the date.”

Where each one is the right answer

This isn’t about declaring two of the dates useless. Each answers a different question:

• Gift date is for donor behavior and revenue attribution: fiscal totals, retention windows, “when did they last give.”
• Entry and batch dates are for operations and finance: how fast gifts are processed, how a deposit ties out to the bank.

Trouble starts only when a revenue report quietly uses entry date, or a “last gift” field shows the batch date.

A worked example

A synthetic year-end gift at Hollow Creek Arts (figures illustrative):

Attribute this $1,000 by gift date and it lands in FY24, where the donor intended it. Attribute it by entry date and it lands in FY25, so your December campaign looks $1,000 short, January looks $1,000 strong, and the donor’s year-end tax expectation no longer matches your books. The gift didn’t move. The date you chose moved it.

The fix

Three decisions, written down once:

1. Name gift date as the attribution date for all revenue and donor-behavior reporting. Everything about “how much did we raise and when” keys off gift date.
2. Reconcile cash on batch/entry date separately, where finance needs it. The two views are allowed to differ. That difference is the timing of processing.
3. Make “last gift date” use gift date, so reactivation and recency logic reflect donor behavior, not staff workflow.

This is the same class of problem as why your reports disagree: an undocumented choice produces a confident number that won’t match the next one. The metric that depends on this most, revenue by period, is defined in the open metric-definitions repository, where the date basis is part of the spec.

What you get

Fiscal totals that reconcile across reports, a year-end number that reflects what donors actually did, and recency logic that doesn’t quietly punish a December donor for your January data entry. One written rule, attribute by gift date, closes a gap most shops have lived with for years.

See where your hygiene stands with the free self-assessment, or explore What Becomes Possible.

Examples use synthetic data. The standard is open and early; treat current releases as drafts.