Planning Center’s reporting gets criticised unfairly. People say it’s limited, and that isn’t quite right — it’s scoped, which is a different thing and mostly a deliberate one.
Inside any single product, the reporting is genuinely good. Services will tell you who was scheduled, who declined, and who hasn’t been given a slot in two months. Giving will produce statements, donor lists and fund breakdowns without complaint. Check-Ins will tell you how many kids came to which service. People will build you a list from any combination of field values you like.
The wall isn’t in any of those. It’s between them.
One login, several databases
Planning Center is a suite. Check-Ins, Giving, Groups, Services, People, Calendar, Registrations and Publishing are separate products that share an account and a person record — and that architecture is why each one is fast, focused, and doesn’t collapse under the weight of the others.
The cost is that a report lives inside a product and can only see that product’s data. Ask Giving a question about giving and you’ll get an answer. Ask Giving whether your donors also serve and there’s nowhere for the question to go, because Services data isn’t in the room.
So the questions that stop you are the ones with an and in them:
- Which of our volunteers have stopped giving?
- Do people in small groups attend more often than people who aren’t?
- Which families registered for the fall retreat and have never checked in on a Sunday?
- Of the people who joined in January, how many are still active in April — and are they the ones who got into a group?
- Which households give consistently but haven’t attended in two months?
Every one of those is a normal thing for a church leader to want to know. None of them can be answered by a report inside a single product, because each one needs two products to compare notes about the same person.
Why the workaround is always a spreadsheet
The standard solution is exports. Pull a giving report, pull a serving list, pull check-in history, drop all three into a workbook, and match them on name or email.
This works, and it’s how most churches answer these questions today. It has three problems that show up in order.
It’s slow — genuinely a morning, sometimes a day, depending on how much reconciling the name matching needs.
It’s stale immediately. The moment you finish, it starts aging. Ask the same question in six weeks and you do the whole thing again.
And it can’t survive a follow-up. You present the numbers, someone asks the obvious next question — is that worse than last year? — and you’re not answering from the spreadsheet you built. You’re building a second one.
That last problem is the real one. Reporting that can’t take a follow-up question isn’t reporting, it’s a snapshot. The interesting stuff in church data is almost never in the first answer; it’s in the third.
The joins that matter
If you’re going to connect Planning Center’s products yourself, these are the combinations worth the effort. Each answers something a single-product report can’t:
Giving × Attendance. Separates the two very different situations that look identical on a giving report: a household in financial trouble, and a household on their way out the door. Still attending and giving less is one conversation. Still giving and gone for two months is a different one entirely.
Serving × Attendance. Volunteers usually disengage in a predictable order — shifts first, then availability, then Sundays. Reading serving against attendance is often the earliest signal available anywhere in your data.
Groups × everything. Group membership is the strongest predictor on your books. Whether people in groups attend, give and serve more than people who aren’t is worth knowing precisely, because it tells you what your groups ministry is actually producing.
Registrations × Check-Ins. Event signups are the cheapest source of new-family names you have. How many of the households that came to VBS ever appeared on a Sunday is a direct measure of whether your events connect to your church.
New members × time. Not how many joined, but how many are still here six and twelve months later — and what distinguished the ones who stayed.
What Planning Center gives you to work with
Two doors out, and it’s worth knowing both exist.
Every product exports CSV, which is what most churches use and what feeds the spreadsheet approach above.
There’s also an API covering every product, which is the door a developer would use — and it’s a good one. Well-documented, stable, consistent. If you have a developer with spare time, this is a real option and plenty of churches have built useful things with it.
The catch is that “spare time” is doing heavy lifting in that sentence. Reading the API is the easy part; keeping a synced copy current, modelling eight products into something queryable, and maintaining it after the volunteer who built it moves away is the part that doesn’t get finished.
Where this leaves you
Three honest options.
Do it by hand when it matters. Perfectly reasonable, especially under a couple of hundred people. Pick two or three questions a year that are worth an afternoon and answer them properly. The mistake is pretending you’ll do it monthly — you won’t.
Build on the API. Right call if you have real developer capacity and specific needs no product will model. Be honest about who maintains it in two years.
Use a layer that already does it. This is what we built Parable for: it reads every Planning Center product nightly into one place where they share a person key, so “givers who also serve” is a query rather than a project. You ask in plain English and the answer comes back as a list of people. There’s SQL and warehouse access underneath if someone on staff wants it.
We’d rather you picked the right one of those three than defaulted to us. If your questions live inside one product, Planning Center already answers them and adding a tool is just another login.
But if you keep ending up in a spreadsheet joining two exports on email address, that’s not a discipline problem. It’s a structural gap — and the fact that the report doesn’t exist isn’t a failure of Planning Center. It’s the predictable consequence of a suite that got the important part right.