The Finance Secretary’s Pre-Approval Checklist for a Church App

Before approving a church app for 500 or more members, confirm what the church will pay, what members can actually use, who controls the account, and what happens at renewal. A polished demo is useful, but the finance decision needs written answers, tested access, and a budget that includes every recurring charge.

Confirm the annual cost, not only the monthly price

Ask for the price by plan, billed monthly and annually, then calculate the first 12 months yourself. Include onboarding, data migration, training, SMS credits, WhatsApp charges, payment processing, branded-app fees, storage, and support if they sit outside the subscription.

A $49 monthly plan becomes $588 before messaging or setup costs. A $99 monthly plan becomes $1,188. Those figures make a better board conversation than “less than $100 a month.”

Request a sample invoice showing taxes, currency, billing frequency, overage rules, and the charge that applies when membership grows. If the app limits members, messages, or storage, identify the point where your church moves to the next tier.

Match plan features to features members can use today

Create a short list of the jobs the church expects the platform to handle in the next six months. For a conference-focused church, that may include event registration, bus selection, QR check-in, real-time attendance visibility, and targeted delay messages. For a weekly member app, it may include events, groups, announcements, and member profiles.

Then ask the supplier to show each item in a live environment using an ordinary member account and an admin account. Avoid approving a plan based on a roadmap item, a mockup, or a pricing-table label.

This matters most for payment and AI claims. If online giving appears in a plan, verify that it can process real payments in your country and ask which payment methods, settlement timelines, fees, and reconciliation exports are available. If a plan includes AI analytics, request a real demonstration using church data, then confirm who can access it and what decisions it supports. A feature that cannot be demonstrated should be marked as unavailable in the approval paper.

For a useful example of why this level of review protects the church, see Nana’s feature audit. Unfinished promises could derail the conference.

Check the cost of communicating at scale

For 500 members, communication costs can become the variable part of the budget. Ask how the app routes urgent updates and what each route costs. A bus delay may require SMS because a push notification can be missed. An event reminder may work through push and email. Those are different operational and financial choices.

Ask for answers to these points in writing:

• Which channels are included in the subscription, and which are charged per message?
• Who pays for SMS, WhatsApp, and email delivery?
• Can finance set a monthly messaging budget or approval threshold?
• Can administrators see delivery reports and message spend by event or branch?
• What happens when the message balance reaches zero?

A platform that can target only registered passengers on a delayed bus helps avoid paying to alert the entire congregation. The value comes from accurate lists, clear permissions, and a coordinator who can send the update quickly.

Set ownership and approval controls before launch

The church, not one staff member or volunteer, should own the billing account, domain settings, payment records, and administrator access. Put at least two trusted officers on the account: one operational owner and one finance or governance owner.

Document who can add paid users, change plans, buy message credits, export member records, and cancel the subscription. If a finance secretary receives a renewal notice after the term has already renewed, the approval process has started too late.

Ask whether the platform supports role-based access. A transport coordinator may need to update a bus route. That person does not need access to billing settings or church-wide member exports. Clear roles reduce accidental charges and protect member information.

Review data, support, and exit terms

Request the data-processing terms before signing. Confirm where member details are stored, what data is collected, who can export it, and how long backups remain after cancellation. Church records include personal information, attendance patterns, and sometimes donation history. Treat access to them as a governance issue.

Also check support arrangements. Find the expected response time for a failed check-in scanner on the morning of a major event, a blocked administrator account, or a delayed notification. Ask whether support is included at your plan level and whether there is an escalation route for event-day incidents.

Finally, read the cancellation and renewal clause closely. Record the renewal date, notice period, price-change policy, and data-export process in the finance calendar. Your church should be able to leave with usable member, event, registration, and attendance records.

Bring a one-page approval record to the board

Prepare a one-page decision sheet with the selected plan, first-year cost, variable messaging assumptions, confirmed live features, account owners, renewal date, and unresolved risks. Attach screenshots or written supplier confirmation for any feature that influenced the decision.

Before inviting 500 members, run a small pilot with administrators, volunteers, and a member group. Test registration, a QR check-in fallback, a bus update, permissions, and a support request. What Happens When a Member Cannot Find Their QR Code at Sunday Check-In? is a useful reminder that the backup path deserves the same attention as the main one.