Invoicing for the church hall

I did a long stint as treasurer of St Columba’s URC (finally stepping down last year). One of our challenges, which I suspect we have in common with a lot of other churches and community groups, was billing for letting out our premises.

Being as we are, bang in the middle of Oxford, and with a variety of different rooms available, we do our best to give something back to the community by renting them out to other charities and not for profits for a reasonable rate … and of course to profit-making enterprises for a commercially appropriate rate.

In the beginning (pre-2009), all of the invoicing and tracking of who owed what was done by hand, with spreadsheets being e-mailed around. This was very labour intensive, and for a number of years after that, we scaled up our lettings by moving to a largely honour-based system which tracked bookings in a Google Calendar and required people to proactively pay us on time via bank transfer.

This sort-of worked for quite a while, but of course many organisations, especially voluntary ones, do not cope well at paying people money if they haven’t been sent an invoice. We had a few embarrassing situations where we invoiced several years of historical debt and caused problems for the people on the other end of it. The bills were perfectly legit, but they had of course spent the money on other things in the interim.

A few years back, things really went downhill for us, and we lost quite a few customers, partly because of our sketchy billing process. Something had to change.

Naturally, I assumed this would be a solved problem – the business of letting a few rooms out with a calendar and invoicing according to a couple of different tariffs is pretty standard and universal. And on first inspection, HallMaster looked to be just the ticket:

  • Aimed at the voluntary sector, like us
  • Reasonably priced
  • Includes invoicing facilities

We ran with it for about eighteen months, but in the end it didn’t work out as hoped, for a few reasons:

  1. Invoicing is not automatic. This was one of the biggest disappointments to me. Most of our customers are “regulars” who book time each month and should get a bill at the end of the month with 30 day terms, covering all their usage that month. Unfortunately, HallMaster only supports issuing invoices as a manual process.
  2. Invoicing is booking-centric, not customer-centric. In HallMaster, you can only issue an invoice for a given booking, not a given customer. One booking can be a repeating series of events, which covers a lot of cases, but unfortunately some of our biggest customers have a couple of repeating series plus lots of smaller ad-hoc bookings. Getting all these onto one “booking” in HallMaster is tedious and error-prone, but if you don’t do it that way, you have to invoice them all separately.
  3. Who owes what is invoice, not customer-centric. Partly because of the above, the view which shows you who owes money lists invoices, not customers. This also means there is no facility (automated or manual) to send reminders to people who haven’t paid.
  4. Interface feels clunky. Somewhat subjective, but the manner in which the Javascript-heavy interface works is a bit iffy. Sometimes it would fail in certain browsers (e.g. Chrome), and sometimes long (tens of seconds) pauses with no progress spinner would occur. Sometimes it would get stuck if you asked for lots of results on one page.
  5. Took them a while to implement SSL. I complained when we first evaluated it that there was no https support (i.e. login details and personal data were being sent unencrypted over the internet to and from their site), and they didn’t take it as seriously as I felt they should (GDPR et al being a concern). They did implement it eventually, but it should have been there from the start.
  6. Confused the customers. It was difficult to remove HallMaster links from the e-mails it sent out, and some customers got confused by them. Customers were supposed to be able to sign up for free to view their invoice and payment history, but sometimes ended up at pages trying to sell HallMaster to venues, which confused them by talking about costs.
  7. Questionable e-mail behaviour. Their system attempted to send invoice e-mails “from” my e-mail address, e.g. invoices@saintcolumbas.org. Unfortunately, while this may have worked just fine in the 90s, these days the advent of SPF and DKIM mean that many spam filtering systems take a dim view of e-mails claiming a from address which the originating system is not authorized to send mail from. To be fair, they did “fix” this for me by setting all e-mails from our account to come from noreply@hallmaster.co.uk, but the ability to set a proper reply-to address would have been much nicer.
  8. No bank integration. OK, so given that Open Banking had barely been invented when we first tried this, a direct feed would have been asking rather a lot. But a simple option to upload a CSV bank statement and assign incoming payments to customers could have been a time saver over entering every payment by hand.

To be fair to HallMaster, I suspect it would work well for smaller venues or those with simpler usage patterns (and those still accepting cheques), but it didn’t hit the spot for us. In particular, it required too much staff/volunteer time to operate.

So what to do? See my next post for what we did.