A childcare vouchers app should record the funding, not try to calculate it.
Search for a childcare vouchers app and you get two different products wearing one name. One is the parent side of a government scheme, and the government already runs that. The other is what a nursery, childminder or after school club actually needs: a record of who owes what, which pot each payment came from, and what is still outstanding on Friday. The second is a narrow slice of childcare management apps, and it is the one worth building.
This page names one real scheme with its exact figures, shows where the subsidy stops scaling, and works through the fields a provider side app has to hold before any of it is useful.
See where the top-up runs outThe short version
The scheme does the arithmetic, your app does the reconciling.
Childcare funding is country specific and it moves. No two schemes share a cap, an age limit or a payment route, and budgets change the numbers. An app that hardcodes one country's rules is wrong the moment it crosses a border and wrong again the next time a threshold shifts.
So the useful build is narrower than it first looks. You are not computing entitlement. You are splitting one invoice across the pots that paid it, matching bank credits that arrive with a reference and no other context, and chasing the gap. That is a ledger problem, and a ledger is very buildable.
One real scheme, with the real numbers
Take the United Kingdom scheme, because it is documented in public and the figures are exact. A parent opens a childcare account and pays into it by Direct Debit, standing order or bank transfer. For every £8 paid in, the government adds £2. That top-up is capped at £500 every 3 months, which is £2,000 a year per child, or £1,000 every 3 months and £4,000 a year if the child is disabled. The child has to be 11 or younger, or 16 or younger if disabled.
Two rules in there matter more to a provider than the headline ratio. The first is the cap. The government stops topping up once £2,000 of parent money has gone in during a quarter, which leaves £2,500 in the account for that period. A setting charging £1,300 a month exhausts it during the second month, and every invoice after that is paid at full price. The subsidy does not scale with the bill, so a fee increase changes the parent's share far more than it changes the scheme's.
The second is reconfirmation. The parent must sign in to the childcare account every 3 months to confirm they are still eligible, and the funding stops if they do not. That is not a payments failure, it is a calendar event that quietly switches off a family's money, and the nursery usually discovers it when a transfer does not arrive. A reconfirmation date on the parent record, with a reminder, is probably the highest value field in a childcare app of this kind.
One more operational detail. A payment into the account usually appears within one working day and the government's share lands at the same time, but the provider has to be signed up to the scheme before a parent can pay them from it. Provider onboarding is a real step with its own lead time, not a checkbox.
Try it
Where the quarterly top-up runs out
UK Tax-Free Childcare figures, per child, per 3 month period.
£150 added, £750 to spend
£350 of the £500 cap is left. It stops once £2000 has gone in. Fees run monthly and the cap runs quarterly, so store the two calendars separately.
The money does not move through your app
This is the part people get backwards when they plan a childcare payment app. Scheme money goes from the parent's government account to the provider's bank account as a transfer. Your app is not in that path and cannot be. What reaches you is a credit on a bank statement with a reference attached. Matching, not charging, is the hard problem, and any design that starts with a card form has already missed it.
For the fees no scheme covers you probably do want to take a card, and there is a platform rule worth reading before you design that screen. Apple's guideline 3.1.3(e) says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. Childcare is consumed outside the app. App Store commission is therefore not your problem, and choosing a payment processor is.
The consequence for the data model is that one invoice ends up with several sources against it: a scheme payment, a card payment, sometimes an employer contribution, sometimes a funded hours allocation from a local authority. Treat the invoice as the parent record and every receipt as a child record. The moment you store a single payment status per invoice you lose the ability to answer the only question anyone asks, which is what is still owed and by whom.
What a provider side app has to store
Start with fields, not screens. A child record needs a date of birth, because age bands drive eligibility in almost every scheme and they expire on a birthday. A funding record needs a scheme name, a start date, an end date, a payment reference and a reconfirmation date where one applies. An invoice line needs the period it covers, because caps run per quarter while fees run per month, and those two calendars never line up neatly.
Then the reconciliation fields. Every incoming payment wants an amount, a date, a source and the reference that came with the transfer. Providers routinely receive money whose reference is a scheme identifier rather than a family name, so the mapping from reference to child has to be stored once and reused forever. Anyone who has done bookkeeping will recognise the shape of the work: it is the same matching problem as a business expense tracking app, with the awkward difference that the payer is a government system and cannot be phoned.
Two things to leave out deliberately. Do not compute entitlement, because you would be maintaining someone else's policy for free and taking the blame when it changes. Do not store more about a family than the invoice needs, because a childcare setting already holds unusually sensitive information about children, and a homemade app is a new place for it to leak.
Which scheme you support decides the app
Here is the honest limit on everything above. Those figures are one country's scheme, taken from the official guidance and correct as published. A tax-free childcare app built to them will be wrong in Ireland, wrong in Australia and wrong in the United States, where the nearest equivalent runs through an employer dependent care benefit rather than a government account. We have not verified the current limits for any scheme other than the United Kingdom one cited above, so do not lift a number from this page into a product for another market.
That argues for one specific design decision. Keep the scheme as data, not as code. A scheme record with a name, a jurisdiction, a cap amount, a cap period, an age limit and a link to the official page lets you support a second country by adding a row and reading one source. Hardcode £500 a quarter and a childcare subsidy app becomes a rewrite the first time a budget moves the number.
It also sets what you are allowed to promise. An app that tells a parent how much top-up they will receive is making a claim about their tax affairs. An app that tells them what has been received against this invoice and what is outstanding is making a claim about your own bank account. Only one of those is yours to make. Where money really does pass through a product rather than beside it, the decisions get harder, and the trade-offs around money moving through an app are worth understanding before you pick a payment route.
What each option gives a childcare setting
| Option | Splits one invoice across pots | Matches bank references | Warns before reconfirmation | Fits the scheme you name |
|---|---|---|---|---|
| Spreadsheet and bank statements | by hand | by hand | No | Yes |
| Generic invoicing tool | partly | No | No | No |
| Accounting software | partly | Yes | No | No |
| Nursery management platform | Yes | sometimes | No | the ones it ships with |
| An app you build | Yes | Yes | Yes | Yes |
Building one around your own setting
Nursery management platforms are priced per child per month and shaped around the thing they do best, which is usually registers, ratios and parent messaging. Funding reconciliation tends to be a tab rather than the point of the product. A setting with twenty families and three funding sources ends up paying for a booking engine in order to get a ledger, and still exporting to a spreadsheet at the end of every quarter.
Newly is an AI app builder. You describe the app in plain English, including the scheme you actually deal with and the fields your invoices carry, and it writes a real React Native and Expo project you own, running it on a cloud simulator while it builds. Plans start at $25 a month and there is no free plan. iOS builds go to TestFlight through your own Apple Developer account, and the Deploy tab has an Android section where one press builds, signs and uploads to Google Play internal testing, and also produces a standalone release APK you can install on a phone directly. There are no built-in payments, so the card processor is still your decision.
Before building anything, take one real invoice from last month and write down every payment that landed against it, including the part nobody paid and the transfer whose reference made no sense. If the app can represent that single invoice honestly, the rest of it is repetition.
Questions people ask about childcare vouchers apps
In practice it is one of two things. For a parent it is the account where scheme money sits and gets paid out to a provider, which in the UK is run by the government rather than by a third party. For a nursery or childminder it is a ledger: which families owe what, which pot paid each part of an invoice, and what is still outstanding. Only the second is a sensible thing to build yourself.
Describe the invoice you actually send
Write out one month of fees, every pot that paid part of it, and the amount still outstanding. Build the app around that record and the screens follow.
Start building