Planning Center reports are built one product at a time. Each of the eight products reports on its own data and nothing else, which is why single-product questions answer instantly and anything with an and in it doesn’t.
Key points
- Every Planning Center product has its own reports, and there is no account-wide reports page. You go to the product the data lives in.
- People Lists is the exception: it filters people using rules from other products, but returns a list of names rather than a comparison of two numbers.
- Home dashboards hold widgets from every product side by side; each still counts inside its own product only.
- Most reports export CSV, so the standard cross-product workaround is two exports and a spreadsheet join.
- The routes past the wall are export-and-join, the Planning Center API, Planning Center’s own MCP connector for conversational answers, and a reporting layer that syncs every product into one place.
“Planning Center reporting is limited” is the lazy version, and it isn’t true. Inside any one product the reporting is good, often better than churches realise, with reports in there nobody on staff has opened. Here is the honest tour: what each product tells you unaided, what it won’t, and what to do about the gap.
Where do Planning Center reports live?
In the product. There’s no central reporting area for the account, which is the first thing that confuses anyone arriving from a single-database church management system. Three things sit slightly above the products:
Home dashboards. Home builds dashboards from widgets you can share with a team, and every product contributes them. Planning Center’s own wording is precise: dashboards “give you information across multiple Planning Center products at a glance.” The widgets sit next to each other. They don’t talk to each other. More on what Planning Center dashboards can and can’t do.
People Lists. Lists filter people on “their information and activity across all Planning Center applications”. That’s genuinely cross-product, with the caveat that rules against a product need permissions in it. It’s the most underused feature in the suite, and the difference between a list, a report and a dashboard is worth getting straight.
Custom reports. People, Services and Calendar let you write report templates in HTML, CSS and Liquid. Real power, real ceiling: you’re formatting one product’s data, not querying across products.
What can each Planning Center product report on?
People
People is the spine. Lists are the main tool: build a rule set, save it, share it, message the results, run an automation, or print it as a report in PDF or HTML.
For raw data, People exports CSV: your whole database, or just the columns showing on a list. Under 500 results it downloads immediately, over that Planning Center emails a link, and both need the “Can export CSVs and reports” permission.
Check-Ins
Check-Ins holds more than most churches use. The event chart graphs unique people checked in by day, week, month or year and exports as CSV, and the event Overview breaks a session into regular, guest and volunteer with the change in first timers against the last session.
Then the reports: custom ones you configure by scope and layout, plus a headcount report holding up to 53 past sessions. First Timers, Missed This Session, Room Roster and Annual Attendance are the standard shapes. Note the ceiling on that last one, where a multi-year view means combining several CSVs by hand.
If attendance is your main question, Planning Center attendance reports and what kids check-in data can tell you go further than this section can.
Giving
Giving has the most complete reporting of the eight, which makes sense given what’s at stake. The reports split by donation and by donor, both filterable by campus, fund, label, stamp and payment source, alongside donor statements, in-kind reports, and payout reports for reconciling deposits against your general ledger. Everything prints or exports to CSV.
Note where donor lists live: in People, built on rules about donation amount, fund and recurring status. That’s the cross-product seam showing. More in Planning Center giving reports.
Groups
Groups reports on ministry health rather than individual behaviour. A group’s overview shows health stats benchmarked against similar group types: member count, how often it met in the last 90 days, turnover. Across groups you get size, role distribution, demographics, and attendance graphed by year, month, week or day as a percentage, average or raw count, exported as a CSV sent by email.
Services
Scheduling reports come in three families. Plan reports print the order of service, scheduled teams, notes and recorded LIVE times as PDF or web page. Matrix reports work across many plans at once: Statuses of People Scheduled, Blocked Out People (open teams), All People, and a Timecard Report totalling the time each person served over the matrix date range. People reports cover blockouts, future schedule, last logged in, assignments and directory.
The timecard report is the one to remember: the closest thing Planning Center has to a volunteer load report, and almost nobody runs it. What it can’t tell you is whether a volunteer who stopped serving also stopped attending.
Registrations
The overview report gives counts by selection type, payment breakdowns, add-on totals and tallies of dropdown and checkbox answers. Paragraph and text answers are excluded. There’s a printable guest list with emergency contacts, forms status and balances owed, plus a customisable CSV export.
For who actually turned up, attendance reports offer rosters, filtered attendee lists, a Home widget and People lists. Two constraints are stated plainly in the docs: roster data “lives exclusively in Registrations and cannot be exported,” and a People list built on Registrations attendance returns anyone who attended any day of an event, not a specific date.
Calendar
Calendar reports on events, rooms and resources: a default report, a basic report by date, room and resource usage, and custom HTML reports. Output is PDF, web page or CSV, though not every type does CSV, and only event creators, event administrators, room editors and resource editors can edit custom reports.
Publishing
Publishing’s Dashboard has an Analytics tab showing Church Center visitors and page views over a timeframe, filterable by app or web, with a sortable per-page path list. Visitors counts unique logged-in users and guests; views counts loads.
That is web analytics, not people analytics. It tells you a sermon page got 340 views. It does not tell you which 340 people.
What each product can and can’t answer
| Product | Answers natively | Doesn’t answer |
|---|---|---|
| People | Who matches this combination of fields and activity | How two products’ numbers compare for the same person |
| Check-Ins | How many came, who came, who missed this session | Whether a person’s own pattern has changed over months |
| Giving | Totals by fund, donor, campus, payout; statements | Whether a lapsed giver is still attending |
| Groups | Group size, meeting frequency, turnover, attendance % | Whether group members give or serve more than non-members |
| Services | Who’s scheduled, who declined, hours served | Whether a volunteer who went quiet is still on a Sunday |
| Registrations | Signups, payments, forms, who attended each day | Whether a registrant ever became a regular attender |
| Calendar | Event and room usage, approvals | Who was in the room |
| Publishing | Church Center visitors, page views, app users | Which people watched or read |
Read the right-hand column top to bottom and the pattern is obvious: every gap needs a second product in the room.
Why can’t Planning Center report across products?
Because it’s a suite, not a database. The products are separate applications sharing an account and a person record, and Planning Center prices them à la carte precisely because they’re independent: People free, Check-Ins by your busiest day, Giving by donation volume. A church might run three of them or all eight.
That architecture is why each product is fast, focused and teachable to a volunteer in ten minutes. The cost lands on questions needing two products at once, which are the reports Planning Center can’t run. And what that hides is usually change in a person over time rather than any single number.
The built-in cross-product tools stop short of a report. A Home dashboard puts a Giving widget beside a Check-Ins widget and neither knows the other exists. A People list can filter on Check-Ins or Giving activity. That’s how the lapsed-giver list and the stopped-attending list get built. But a list returns names, not a comparison.
What are the ways past it?
Export and join in a spreadsheet
The default, and for a one-off question it’s the right call.
- Export the CSV from each product involved.
- Put each on its own tab.
- Join them with a lookup on person ID or email, never on name. Name matching breaks on nicknames, on marriages, and on households that file under one spouse some years and the other in others.
- Answer the question, date the file, and accept that it’s a snapshot.
Expect a morning; getting Planning Center data into Google Sheets covers the mechanics, and how that compares to a purpose-built tool is written up separately. The failure mode isn’t the first export, it’s the follow-up. Someone asks whether that’s worse than last year, and you build a second workbook.
Ask Planning Center’s own AI connector
Planning Center connects to AI tools over MCP, and it will cross products in a way no report does. Point Claude or ChatGPT at mcp.planningcenteronline.com/mcp and Planning Center’s own example question is who’s scheduled to serve this Sunday but isn’t in a small group. Anyone with a login can connect, and they see only what their permissions already allow.
What you get back is a conversation, not a report. There’s nothing to save, schedule or send to a board pack, no history kept between questions, and no second person seeing the same number next week. Every question re-queries the account live. It’s excellent for the question you have right now, and it’s the fastest of these four routes to try. It isn’t the weekly number you run your staff meeting on.
One caution the help page raises itself: unless your church is on a commercial plan with Anthropic or OpenAI, those companies may train on your conversations by default, and your conversations here contain member data. Both offer a setting to turn that off. Check it before you connect.
Build on the API
The API is good, and it’s the door a developer would use. Every product is its own OAuth scope, personal access tokens cover scripts you run yourself, and the default rate limit is 100 requests per 20 seconds per authenticated user, with headers on every response telling you where you stand.
Reading the API is the easy part. Keeping a synced copy current, modelling eight products into something queryable, and maintaining it after the person who built it moves on is what doesn’t get finished. If you have real developer capacity, start with the data-team view of Planning Center and what we expose to technical teams.
Put a reporting layer on top
This is what we built Parable for. It reads all eight products through the API 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 get a list of people back, with dashboards for the numbers you watch weekly and SQL underneath on the larger plans.
I’d rather you chose honestly than defaulted to us. If your questions live inside one product, Planning Center already answers them and a second tool is just another login, and how we compare to Planning Center itself says so. The FAQ covers the rest.
Which route fits your church?
Under a couple of hundred people, do it by hand two or three times a year and do it properly. The mistake is planning to do it monthly. With a developer on staff who’ll still be here in three years, build on the API.
If you keep finding yourself joining two exports on email address at eleven at night before a board meeting, that’s not a discipline problem and it isn’t Planning Center failing. It’s the predictable cost of a suite that got the important part right, and it’s a solved problem.