Taking Payments for Events
Andy,
I'm trying to figure out a way to work around some different event types and we had a couple ideas that I would like feedback on. There are two types of events. One where we take payment (deposit) first and then sell the product on the day of the event. Another where we take payment later for an earlier event.
For the first type of event where payment (deposit) is taken in advance we are thinking of selling a "gift card" of a certain special code for the event that includes the type of event and event date and time. Then on the day of the event we sell the actual product (birthday party or other type of deposit event) and apply the "gift card" (deposit) and have the customer pay the difference.
For the second type of event where we take payment later for an event that occured previously, we are thinking of doing a couple things. First of all, these types of events are billed to entities so we would change these "customer types" to Entity. Next give them bogus direct billing information so that we can invoice their account on the day of the event (or change the invoice date to the day of the event) and the customer/entity can pay later.
This way the event product is invoiced on the day of the event (to keep good records) and money can be taken in either previously or later. Let me know if you see any bugs or cracks in either of these methods.
Thanks,
-Josh
Comments
Hi Josh,
#1 - that seems like a fine way, though it does seem somewhat complicated. Is there a compelling reason to not sell a "Birthday Deposit" product at the reservation...and then sell the "Birthday" product on the day of the event? If you need to confirm the deposit, you can just look up the customer's invoice/account history? That is what my gym, and most seem to do.
#2 - My first thought is that if this is a truly "accounts receivable" type of transaction... then to use Quickbooks (or whatever accounting package you use) to invoice the customer properly. Just create a paper form representing the event, complete it on the day of the event, and then a manager can periodically review those and enter them as true A/R invoices into Quickbooks. There are a million details about invoicing businesses that RGP does not support (past due notices, penalties, etc.) and in my opinion you should use the tool designed for that - an accounting package. Sure RGP won't contain a complete record of the gyms "sales" for that day, but that isn't bad. Quickbooks should be the ultimate source for that information.
#1 - It is somewhat complicated, however I believe it would keep better records. I also like the idea of selling the nontaxed birthday deposit as a line item and then returning it on the date of the event while selling the actual birthday product.
#2 - I guess we end up doing that and also putting it through RGP. It seems the problem is just keeping track of the date of the event and the date of payment through RGP. That's why I think Invoicing on the Date of Event and taking payment later on would be smooth. However, I can't invoice anything unless RGP thinks it is an EFT member with valid direct billing info. Would a nice solution be to allow invoicing to entities?
Also, what's the scoop on the future of RGP? What features might be coming out next? Just curious...
Thanks,
-Josh
My main feature this Summer will be multiple gym support. It is a big, complicated feature. But there will always be the little features that get released periodically.
Cheers
Andy
Recalling a very old post...
# 1 Seems to now be handled (or recommended) to sell a generic deposit and then refund on day of and charge the regular price. This is what I have seen for examples using the booking system and I feel it works great and also provides more accurate sales of each booking without having generic deposits pull reported revenue from the programs' revenue.
#2
How can we handle similar events. We want to be able to book and track programs and groups through the calendar and get fairly accurate programming revenue reports out of RGP. This means that we need to invoice and charge a customer or entity day of (potentially also accounting for any previously paid deposits, but that could be handled like #1).
Any way you would recommend we do this? Perhaps have the full amount owed remain in the calendar and when they pay, apply the transaction? But that may show a higher program revenue a month or 2 after the actual events.
What do you recommend?
Please sign in to leave a comment.