I spent a few years as the data lead at a ten-campus church, and the request that ate the most of my time was also the most reasonable one anybody made: how did each campus do last month?
Not a hard question. Attendance, giving, guests, per campus, side by side. Every campus pastor wants their own row and leadership wants the total. It took days, and the reason wasn’t that the data was missing. It’s that “campus” means something slightly different in every Planning Center product you’d need to pull from, and in two of them it barely exists at all.
If you run multi-site, this is the article I wish someone had handed me in week one.
Campus is not one thing in Planning Center
Planning Center is a suite of separate products sharing a person record, and campus support arrived in each at different times for different reasons. Here’s what you’re actually working with:
| Product | Where campus lives | How many per record |
|---|---|---|
| People | A real Campus record: name, address, timezone. Each person has a primary campus. | One |
| Giving | Campus records, and a donation carries a campus, stamped from the donor, overridable per gift. Recurring schedules and pledge campaigns carry one too. | One |
| Check-Ins | Not on locations. Campus attaches to the event. | Several |
| Groups | Campus records. A group is set to All campuses or to specific ones. | Several |
| Registrations | Campus records, and a signup can be assigned to campuses. | Several |
| Services | Only on folders, the containers that organise service types. Not plans, not teams. | One |
| Calendar | No campus field at all. Campus is a tag. | n/a |
One piece of genuinely good news is buried in there. Where two products both know about a campus, they mean the same campus: the underlying campus identifier is shared across People, Giving, Groups and Registrations. I’ve checked this across every multi-site church whose Planning Center data we sync and the identifiers line up. Campus is defined once for your organisation, not reinvented per product.
Everything else in that table is a trap, and the third column is the worst one.
The trap in the third column
In People and Giving, campus is singular. One person, one primary campus. One gift, one campus. Those campus buckets add up to the all-church total only when you include an explicit Unassigned bucket. Drop the people or gifts with no campus and the visible campus rows will understate the organization.
In Check-Ins, Groups and Registrations, campus is plural. An event, a group or a signup can belong to several campuses at once, which means it can land in several buckets, so summing your campus rows can overstate the total. Check the assignment cardinality before treating any of those breakdowns as additive.
If you take one thing from this article, take that. Attendance and registration numbers broken out by campus are not automatically additive, and nothing warns you.
Per-campus attendance
Check-Ins does support campus, on the event. What it doesn’t have is campus on locations, so the room hierarchy inside an event tells you nothing about site.
The catch is that the event campus field is not always populated consistently. In practice, campus in attendance data may be an explicit event assignment, an event-per-campus naming convention, or a top-level location hierarchy. Before reporting, identify which model the church actually uses and how unassigned events should be handled.
Two common shapes. One event per campus, “Sunday Gathering – North” and “Sunday Gathering – Downtown”, which is easy to read, annoying to maintain, and multiplies every time you add a service time. Or one event with campus as a top-level location: a single “Sunday Gathering” with North, Downtown and Online as parent locations and the rooms nested underneath. I’d recommend the second, because campus and room come out of the same hierarchy.
Either way, the manual pull is:
- In Check-Ins, open the event covering the period you want.
- Choose a time frame using the date picker at the top of the event chart.
- Switch the chart’s grouping from Kind to Location, so the location standing in for campus becomes the breakdown.
- Export CSV.
- If campus lives on the event rather than on a location, repeat for each campus event and combine the files in a spreadsheet. The chart will let you select several events together and export them, but the Location grouping is only offered when a single event is selected, so the multi-event export is the one that cannot give you the location breakdown.
If you want tabulated numbers rather than the chart, the event’s reports are a choice between a Custom Report, where you pick the parameters, and a Headcount Report, which skips them and totals check-ins grouped by Time or Type. Watch the ceiling on that second one: it’s scoped by how many past sessions to include, 53 at most, not by a date range. For a weekly event that is roughly a year; for other cadences it is simply 53 sessions.
The event chart does more of the first roll-up than people expect: timeframes, multiple event selections, location grouping and CSV export are all there. What it will not do is combine the last two. Location grouping appears only with a single event selected, so the breakdown that stands in for campus is a one-event-at-a-time affair, and several campuses usually means several exports stitched together in a spreadsheet. The spreadsheet is needed anyway when campus is encoded inconsistently across events, when anonymous headcounts lack a campus dimension, or when attendance must be combined with another product.
Two things corrupt this before you start. Naming drift: “Kids – North” in one event and “North Kids” in another gives your spreadsheet six campuses instead of five. And headcounts, which are anonymous: a typed-in adult count has no person, so its campus can only come from the event it was logged against. Headcounts on one all-church event have no campus at all.
Per-campus giving
Giving is the surprise. People will tell you Planning Center Giving can’t do campuses, and that isn’t right: a donation carries its own campus, drawn from the same shared campus list as People.
But read carefully what that campus means. Planning Center’s guidance is that when no campus is selected or overridden, Giving defaults the donation to the donor’s primary campus in People, not necessarily where the gift was physically received. In an aggregate Parable snapshot on 1 August 2026, across multi-site integrations with donations, matched donor-primary and donation campus values agreed between 77% and 100%. That range describes the connected sample on that date, not a universal Planning Center benchmark.
That default is not a locked door, though, and the three ways round it are worth knowing. Entering donations in a batch, every donation gets its own campus dropdown, preselected from the donor’s profile and changeable right there. Switch on Display a campus selector for your online donation form and the donor chooses the campus themselves, defaulting to their profile’s campus if they’re signed in. And Bulk Edit Donations will reassign campus across an entire fund or label in one pass, retroactively.
Inheritance is the default, but a form selection, batch entry or bulk edit can legitimately produce a different campus. Unless your process records where a gift was intended or received, “giving by campus” commonly means giving by the donor’s assigned campus. If a family attends North but their People record still says Downtown, a defaulted gift counts for Downtown. Do not infer from a 100% agreement rate that nobody ever overrode a gift; verify the configuration and the actual records.
Then there’s coverage. In the same dated snapshot, seven integrations with more than one active People campus and donation data ranged from about 9% to 98.5% of donations carrying a campus. The important practice is not the range; it is calculating your own assigned and Unassigned shares before trusting a per-campus report.
Before building anything: filter donations by each campus in turn for last month and add up what those filters return. Giving’s campus filter has no documented Unassigned option, so the unattributed figure is arithmetic rather than a filter setting: take the period total and subtract the sum of the campus filters. An unattributed gift may have no matched donor, a matched donor with no primary campus, or an explicit blank/unsupported campus path. Keep those causes separate during cleanup.
Funds and batches have no campus of their own. A batch is just a container, and it can hold gifts stamped for five different campuses. Campus does reach past the individual gift in two places, both new as of 13 July 2026: a pledge campaign can be assigned a campus, and a donor can pick a campus on a recurring donation, with admins able to edit the campus on an individual recurring schedule afterwards. Churches that set their giving up before the campus field existed, or who never turned the form selector on, fall back on one of two conventions:
Campus-specific funds: “General Fund – North”, “General Fund – Downtown”. Planning Center’s own guidance now reads two ways depending on which page you land on. The older multi-campus setup guide still tells you to create a fund per campus, so the fund records the donor’s intended destination for the gift. The July 2026 Giving release recommends the opposite shape: a unified fund structure with campus carried on the donation, backed by bulk tools that migrate campus-specific funds onto a consolidated one. Neither reading has been withdrawn, so citing “what Planning Center recommends” settles nothing. The cost of the older shape is a larger fund structure, and that is still not automatically a reason to remove it: donation campus and fund can answer different questions.
Batch or envelope conventions: physical gifts batched per campus at counting, so the batch description carries what the field doesn’t. This one is now mostly a holdover: the per-donation dropdown does the same job as a real field, and a description is not something you can group a report by.
Neither is wrong. Both are conventions rather than data, so they hold exactly as long as the person who invented them stays on staff. The rest of what Giving’s reports can and can’t do is in the Planning Center Giving reports guide.
The roll-up problem
Say you get through all that. You have attendance per campus and giving per campus. You still don’t have what leadership asked for.
Any ratio that crosses Giving still needs your own join. Planning Center Home can put attendance and Giving widgets on the same dashboard, and Check-Ins can export several campus locations from one event in a single chart. Planning Center’s official AI connector goes further and answers live cross-product questions, but it reads People, Check-Ins, Groups, Registrations and Services, not Giving. So giving per attender, the one ratio a multi-site board actually asks for, is exactly the one nothing built in will calculate: a custom ratio with your chosen campus, date and denominator rules. That calculation belongs in a documented spreadsheet or another analysis layer, not in 120 values copied by hand.
Assigned campus and activity campus answer different questions. A historical donation keeps the campus stored on that donation unless somebody bulk-edits it. Historical Check-Ins attendance remains attached to its event and location; changing a person’s primary campus in People does not rewrite those old attendance records. Decide explicitly whether a report means the person’s campus now or the campus recorded on the activity then. Both can be defensible, and two reports in the same board pack should never quietly use different ones.
Households don’t have a campus. Primary campus sits on the person. A family attends North; dad’s record still says Downtown from when they joined in 2019; the kids often have no campus at all, because a child’s profile is rarely the one anybody edits. That last gap is narrower than it was: since 28 October 2025 Church Center fills in a campus on a profile that has none and prompts when the campus it sees disagrees with the one on file. Whether that reaches the other members of a household is undocumented, so check your own data rather than assume it does. Then count households per campus and see what happens.
Coverage here is as uneven as the giving numbers. In the 1 August snapshot, ten integrations with more than one active People campus ranged from 0% to 99.9% of people carrying a primary campus; four sat in the 50–85% band. If two-thirds of your people have a campus, a per-campus membership count that drops Unassigned is two-thirds of a number, and any per-person ratio needs that missing denominator shown.
Which leads to the one rule I’d enforce on any multi-site report, whoever builds it:
The campus breakdown must reconcile to the all-church total, with an explicit “Unassigned” row.
Not a footnote. A row, on the report, with a number in it. The moment unattributed people and unattributed gifts get silently dropped, your campus report and your board report disagree, and someone notices at the worst possible moment. An Unassigned row that shrinks quarter over quarter is also the only honest measure of whether your data hygiene is improving.
And if you’re going through exports or the API, do not join campus by display name when a stable campus ID is available. Names can be renamed, punctuated or capitalized differently in exported labels. Keep a mapping table for sources such as Check-Ins locations that do not expose the shared campus ID, and treat normalized names only as a reviewed fallback.
What I’d fix inside Planning Center first
None of this needs new software, and all of it makes any tool you eventually use work better:
- Write down which field is the campus system of record. For most churches that’s the person’s primary campus in People. Everything else reconciles to it.
- Map the Check-Ins structure explicitly. Use event campus where it fits, and keep a reviewed mapping from top-level event/location IDs to campus IDs where locations carry the reporting meaning. Matching names helps humans, but IDs keep the join stable through a rename.
- Decide what campus-specific funds mean before changing them. A donation campus can represent the donor or gift assignment; a campus-specific fund can represent the donor’s intended destination. Keep both when they answer distinct questions. Consolidate funds only when finance and ministry owners agree the second dimension is redundant, and preserve the historical mapping.
- Backfill primary campus in People. This is the highest-leverage hour on the list by some distance, because it’s the one field that fixes your people counts and your giving report at the same time. Start with households that gave or checked in this year.
Do those four and the exports get much less painful. They don’t stop being exports.
Where this ends up
The honest summary is that Planning Center models campus well inside the products that expose it. Reporting across campuses means reconciling a field that’s singular in two products and plural in three, absent from Services except on folders, represented by a tag in Calendar, and incomplete to a different degree in every organization.
That reconciliation is what we built Parable to stop doing by hand. It reads every Planning Center product nightly into one place where campus is a first-class dimension: the campus identifiers from People, Giving, Groups and Registrations resolved to one list, Check-Ins events and locations mapped onto it, additive and non-additive sources kept apart so nothing double-counts, and unassigned records shown rather than dropped. We spent real engineering time teaching our report builder how campus joins work across those products, precisely because getting it wrong in five different ways is the default.
Practically, “compare attendance and giving by campus, this year versus last” becomes a question you type, answered as a dashboard per campus plus a combined view. If you’re still deciding what those dashboards should contain, the church dashboard blueprint covers the metrics worth putting on them.
But automated or not, the sequence is the same: define person assignment and activity campus separately, map the product fields explicitly, measure how much data is tagged, know which numbers are additive, and never publish a breakdown that does not reconcile to the whole through an Unassigned row.
Multi-site reporting isn’t hard because the numbers are complicated. It’s hard because five products have five different opinions about where somebody goes to church. For the rest of what Planning Center reporting can and can’t do, product by product, start with the complete guide to Planning Center reports.