The spreadsheet that runs your church did not start out risky. It started out as one tab, one person, one clear list of names and phone numbers. Then a second person got edit access, then a giving column got added, then someone built a formula to total attendance by month, and now it is the place where four different jobs happen at once with no one fully in charge of any of them.
None of that is a criticism of the person who built it. It is what happens to every shared file that survives long enough to matter. The risks below are not hypothetical edge cases — they are the ordinary, boring ways a single shared spreadsheet fails a small church, usually without anyone noticing until the damage is already a few months old.
Two people editing at once, one edit wins
Most church spreadsheets live in Google Sheets or a shared Excel file, which means more than one person can have it open at the same time. That sounds like a feature. In practice it means two people can update the same household's row within minutes of each other, and depending on the tool and the connection, one of those edits simply disappears. Nobody gets a warning. The file saves cleanly either way.
This is worse than it sounds because the overwrite is invisible at the point it happens. The volunteer who typed in a new address has no idea their change didn't stick. The person who overwrote it has no idea they overwrote anything. The gap only surfaces later, when a card gets mailed to the old address or a follow-up call goes to a disconnected number, and by then nobody remembers there were two edits in the first place.
No real history of who changed what
Version history in Google Sheets exists, technically, but almost nobody at a 150-person church is going to scroll through hundreds of timestamped revisions to figure out when a giving total changed or who deleted a row. In practice, a spreadsheet has no usable audit trail. A number is either what it currently says, or it isn't, and there's no clean way to ask “what did this say last month, and who touched it.”
That absence is fine right up until it isn't — until a giving total looks wrong before a board meeting, or a family disputes what they gave, or a volunteer swears they logged a visit that isn't there anymore. A record without history can't settle that kind of question. It can only be argued about.
One broken formula, and nobody knows for how long
Every church spreadsheet eventually grows a formula: a running attendance total, a giving sum by fund, a lookup that pulls a household's group from another tab. Formulas are fragile in a shared file. A sorted column that should have stayed put, a row inserted above a range instead of inside it, a copy-paste that dragged a relative reference somewhere it shouldn't have gone — any of these can silently break a formula while leaving a number in the cell. It still looks like a total. It just isn't counting what it used to count.
The dangerous part is the lag. A broken formula in row 40 might sit there for three months before someone cross-checks it against a bank deposit or a printed roster and realizes the number has been wrong since spring. There is no alert for a quietly broken formula. There is only the moment, later, when someone finally asks why the totals don't add up.
One file, one person who understands it
Ask most churches who actually knows how their spreadsheet works — which tabs feed which formulas, why a certain column is coded the way it is, what the color-coding means — and the honest answer is usually one person. Often it's whoever built it. When that person is out sick, changes roles, or moves on, the file doesn't stop working, but it stops being understood. The next person inherits a structure they didn't design and are afraid to touch, so they build a workaround next to it instead of fixing it, and now there are two systems of truth in one workbook.
This is the same risk that shows up in a database that has drifted over the years: the fix gets harder the longer it's deferred, because every month adds more rows built on a structure nobody fully explains anymore.
No real separation between people, giving, and notes
A shared spreadsheet almost always ends up doing three jobs at once — a directory of people, a log of contributions, and a scratchpad of notes about who's struggling or who just had a baby — because adding a new tab is easier than building a second system. The trouble is that these three things have different sensitivity and different audiences. Giving records should be seen by very few people. Pastoral notes should be seen by fewer still. In one shared file, access is usually all-or-nothing: whoever can open the workbook can see everything in it, including the fund a family gives to and the private note about their situation.
That's a real trust problem, not just a tidiness one. Giving deserves to be handled with more care than a shared tab allows, and pastoral notes deserve a home that isn't sitting a few tab-clicks away from a general volunteer roster.
Nothing ages, so nothing gets followed up on
A spreadsheet is a static list. It does not notice that a guest from six weeks ago has no owner assigned to their follow-up, or that a volunteer has been on the schedule four weekends running with no break. A row just sits there, unchanged, until a person happens to scroll past it and remembers to look. In a church small enough that one admin reads the whole sheet every week, that might be enough. As the list grows, it stops being enough, and the rows that most need attention — the guest nobody followed up with, the volunteer headed for burnout — are exactly the ones that are easiest to scroll past.
SundayBridge exists mostly to close that gap: a follow-up gets an owner and a date, and it ages visibly if nobody picks it up, instead of sitting quiet in row 214. It won't decide who should own it or when to call — that's still a person's judgment — but it will stop letting the question go unasked.
The risk compounds with every new hand on the file
A spreadsheet with one editor is a diary. A spreadsheet with six editors is a shared filing cabinet with no lock on any drawer, and most churches slide from the first into the second without ever deciding to. A new volunteer gets added to the sharing settings because it's faster than asking the admin to make every update themselves. A staff member gets a copy emailed to them “just this once” and starts editing that copy instead of the live one. Each addition is reasonable on its own. Together, they turn one file into an unofficial multi-person system with none of the safeguards a real one would have.
The people who add themselves to that list rarely mean any harm. They're trying to help — updating a phone number after a conversation at coffee hour, logging a gift before they forget. But every one of those good intentions is another chance for a collision, another person who half-understands the file's conventions, another version of the truth quietly diverging from the rest. The risk isn't any single edit. It's the number of people who can make one without anyone else knowing it happened.
What actually reduces the risk
You don't have to abandon the spreadsheet today to reduce its risk tomorrow. Reconcile giving against bank deposits on a fixed schedule so a broken formula gets caught in weeks, not months. Restrict who has edit access to the whole file, even if that feels unfriendly, so two people are less likely to collide on the same row. Keep pastoral notes out of the same tab as the directory, full stop. And write down, somewhere durable, what each formula and column actually means, so the file survives the person who built it.
None of that removes the underlying issue — a spreadsheet still has no idea what a household, a gift, or a follow-up is, so it can never enforce any of this on its own. It just gives you a smaller version of the risk instead of the whole one. If you're starting to feel the size of that gap, our guide to moving off spreadsheets walks through doing it without losing anything, and choosing church management software covers what actually matters when you go looking for the next tool.
The spreadsheet rarely fails all at once. It fails one overwritten cell, one silent formula, one unassigned row at a time — which is exactly why it takes so long for anyone to notice.