Consign.Tech
Case Study

Building a Church Management Platform: What the Spreadsheets Were Hiding

15 December 2025  ·  7 min read

When a church came to us with a membership management problem, we expected something straightforward. A few hundred members, giving records, attendance — it sounded like a few weeks of work. Eighteen months later, we had built one of the more complex administrative platforms we've delivered. Here's what we learned.

The Starting Point

The church was managing everything in Excel and WhatsApp. Over 2,000 members, each with a complete history in the congregation: when they started attending, when they were baptised, which cell group they belong to, what roles they serve in, their giving history for the last five years. All of it lived in a collection of Excel files maintained by two full-time administrative staff.

Every Sunday, giving was recorded on paper collection sheets. On Monday, someone transcribed the numbers into Excel. Every quarter, someone compiled a giving summary for the finance committee. Every year, someone generated the giving statements for members who needed them for income tax deductions under Section 80G. The process worked — but it required those two administrators to be available, accurate, and consistent at all times. When one went on leave, things fell behind. When a spreadsheet was accidentally overwritten, records were lost.

The Complexity That Surprised Us

Membership, it turns out, isn't binary. You're not simply a member or not a member of a church. There's a lifecycle, and every stage has different implications:

  • Visitor: someone who has attended once or twice, no formal relationship
  • Regular attendee: someone who attends consistently but hasn't formally joined
  • Member: someone who has gone through a membership class and been formally received
  • Baptised member: specifically for congregations where baptism is a separate milestone from membership
  • Serving member: someone with an active service role — worship team, youth ministry, technical team, etc.
  • Leadership: cell group leaders, department heads, elders — with different access to congregation information and different pastoral responsibilities

Each stage has different pastoral responsibilities attached. A first-time visitor gets a welcome message. A member who misses three consecutive weeks gets a pastoral follow-up. A cell group leader needs to see the contact details of everyone in their cell. A finance committee member needs to see anonymised giving summaries but not individual giving records.

Getting the permission model right — who can see what, and when — took significantly longer than building the underlying data structure.

Financial Workflows

Church finances have specific requirements that general accounting software doesn't handle well:

Multi-stage approval chains: any expenditure above a certain threshold (typically ₹5,000–10,000 in the churches we work with) needs to go through a defined approval process: proposed by a department head, reviewed by the finance committee, approved by senior leadership, then processed for disbursement. Every stage needs to be logged with a timestamp and the approver's name. This isn't just good governance — it's what trustees and external auditors require.

Cash reconciliation: collections at services are physical cash counted by multiple counters (to prevent misappropriation). The system needs to record the count, who counted, and reconcile against the bank deposit the following day. Discrepancies need to be flagged, not silently absorbed.

Fund accounting: many churches maintain separate funds — a building fund, a missions fund, a benevolence fund — each with its own budget and restricted use. Donors giving to a specific fund need to see their contribution reflected correctly in giving statements.

Giving Management and 80G Compliance

In India, donations to registered charitable trusts are eligible for income tax deduction under Section 80G of the Income Tax Act. This means the church's giving receipts need to include specific information: the donor's PAN number, the trust's registration number and 80G certificate details, and the correct wording required by the Income Tax Department.

Every donation needs a receipt. Those receipts need to be retrievable for up to seven years. At the end of each financial year, every donor needs a consolidated statement of their donations for the year — formatted correctly for submission with their tax return.

Generating these statements manually from Excel files was a multi-day exercise. The platform generates them on demand, correctly formatted, ready to send directly to donors.

QR Check-In: Solving the Sunday Morning Bottleneck

Large services — 500+ people attending Sunday morning — had a familiar problem: 20 minutes of chaos at the entrance as ushers tried to mark attendance manually. Paper lists, names called out, people waiting to be found in the register. By the time the service started, half the congregation hadn't been marked yet.

The solution was QR-based self check-in. Every member gets a unique QR code — printed on their membership card, or saved on their phone. They scan it at the entrance. The system records their attendance with a timestamp and updates their attendance record in real time. The queue effectively disappears. Late arrivals are still captured. The pastoral team can see attendance in real time during the service.

For children's ministry — where parents need a matching claim ticket to collect their child — the QR system generates a paired ticket at check-in, solving both the attendance record and the security concern simultaneously.

What We'd Do Differently

We built too much in v1. The membership module alone — lifecycle management, permission model, contact management — took six weeks. Finance took another eight. Events and check-in took four more. We were eighteen months in before the first department was running entirely on the platform.

In retrospect, a phased approach would have delivered value earlier and let us learn from real usage before building everything:

  • Phase 1 (weeks 1–8): core membership directory and contact management. Just get the data structured and accessible. Replace the Excel directory.
  • Phase 2 (weeks 9–16): giving management and receipt generation. This delivers immediate, measurable value — the finance team's weekly work gets cut significantly.
  • Phase 3 (months 5–8): financial workflows and approvals. Build on the giving module once it's bedded in.
  • Phase 4 (months 9+): events, check-in, and the more complex features.

The membership lifecycle system we built in v1 had features that the pastoral team didn't start using until month twelve. We could have built a simpler version first and extended it once we'd seen how they actually worked.

Church management software, done properly, is more complex than HR software for a similarly-sized organisation. The multi-role permission model, the fund accounting requirements, the compliance obligations, and the pastoral workflows all add layers that don't exist in standard business software. If you're a church considering a bespoke platform, plan for it to take longer than you expect — and start with the parts that will deliver the most immediate relief to your administrative team.