How to record advance meal payments in QuickBooks for a nonprofit event
A community answer explains the correct debit and credit entries when event attendees pay ahead, clarifying why the initial credit is a liability rather than revenue.
When a small nonprofit collects advance payments for event meals, the bookkeeping entry isn’t always intuitive — and a common mistake is recording the incoming cash straight to a revenue or expense account. A community thread on the question walks through the correct double-entry approach and explains why the timing of the entry matters.
The scenario
A volunteer bookkeeper preparing a nonprofit’s records asked how to log payments that came in ahead of a fundraising dinner. Their instinct was to debit the checking account and credit the Events/Food account — essentially treating the payment as event income the moment it landed. The question was what the balancing credit should actually be.
Why the initial credit isn’t revenue
The accepted answer in the thread corrects a core misunderstanding: money received before the event has been delivered is not yet earned income. Until the organization actually provides the meal, it owes the purchaser something — a seat, a plate, or a refund. That obligation is a liability, and it belongs on the books as one.
The recommended initial entry is straightforward:
- Debit the checking or cash account for the amount received. This records the increase in funds.
- Credit a liability account created specifically for the event. This records the organization’s obligation to deliver what was paid for.
If someone reserves a meal but hasn’t actually paid yet — just promised to pay — the debit shifts from checking to accounts receivable. The credit side stays the same: the event-specific liability account.
The reasoning is that the liability is as real as a bank loan. The organization is holding someone’s money against a future commitment, and that commitment doesn’t disappear simply because the cash is already in the door.
The follow-up entry after the event
The liability doesn’t convert to revenue automatically. The day after the event takes place — once attendees have received their meals — the bookkeeper records a second entry:
- Debit the event liability account to clear the obligation.
- Credit the event revenue account to recognize the income.
At that point the transaction is complete. The original payment is sitting in checking, and the revenue is recognized in the period the event actually occurred, which aligns with standard accrual-basis reporting.
Handling a cancellation
If the event is called off and the organization refunds the payments, the bookkeeper records the reverse of the initial entry — the liability comes off the books and the cash goes back out. No revenue is ever recognized.
Setting this up in QuickBooks
In practical terms, a nonprofit handling this in QuickBooks Desktop or QuickBooks Online would want to create a dedicated liability account tied to the specific event or the events program generally. Using a generic “unearned revenue” catch-all can work for a single event, but separate accounts per event make it easier to confirm that each liability clears properly after the event passes.
The revenue side should map to the organization’s event or program income account. If the nonprofit tracks restricted vs. unrestricted net assets — common in nonprofit accounting — the initial liability and subsequent revenue entry should be coded to the appropriate fund or class so that grantors and board members can see the event’s financial picture clearly.
For volunteers catching up on several months of entries at once, the key is consistency: every advance payment gets the same two-step treatment, and every event gets its clearing entry once it’s over. Mixing the timing — recognizing some payments as revenue on receipt and others after the fact — is what creates the kind of month-end confusion that prompts these questions in the first place.
The bottom line
The thread’s core lesson applies beyond nonprofit dinners. Any time a business or organization receives payment before delivering the product or service, the credit belongs to a liability account, not to revenue. The income follows the delivery, not the deposit.