Planning Center reports can’t cross products. Each report lives inside one product, whether Giving, Services or Check-Ins, and can only see that product’s data, so any question that joins two, like which volunteers stopped giving, has no report to run.
Key points
- Planning Center reports are scoped to one product at a time, so Giving cannot see Services data and Check-Ins cannot see Groups data.
- The questions that stall are the ones with an and in them: which volunteers stopped giving, whether group members attend more, which registrants never came on a Sunday.
- The standard workaround is exporting CSVs from each product and joining them on person ID or email, which costs hours and is stale the moment it’s finished.
- Planning Center’s API covers every product and is well documented, but building on it means owning a synced copy of the data and maintaining it for years.
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.
Why can’t Planning Center report across products?
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. 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. That boundary, and what it hides inside each product, is the whole shape of the problem.
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 does every workaround end in 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? 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.
Which cross-product reports are worth building?
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.
The lapsed-giver list is the exception worth knowing: it comes out of Giving alone, and only turns cross-product when you ask whether those households are still attending.
How do you get data out of Planning Center?
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, and how we compare to the alternatives is written down.
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. 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.