Vocational Training Software: Fixing the Funding Claim Leak

Why training management software makes or breaks a vocational provider

Every vocational provider I have worked with runs on the same four-legged stool: an LMS (Learning Management System) for content delivery, a spreadsheet for the funding claim, an email inbox for employer sign-off, and one person who knows how it all fits together. Take that person out for two weeks and the claim goes in late. That is not a software problem in the abstract. That is a quarter of your cash flow sitting in a Google Sheet called Claims_MASTER_v7_FINAL_USE_THIS.

The named tools are familiar. Moodle or Canvas for course delivery, sometimes Totara if someone made the compliance argument years ago. Maytas, PICS or Aptem on the funding and apprenticeship side if you are in the UK, with OneFile or Smart Assessor bolted on for the e-portfolio. Salesforce or a light CRM (Customer Relationship Management) like HubSpot for enquiries. Xero or QuickBooks for invoicing. Then a stack of spreadsheets that exists purely because none of those systems talk to each other: the cohort planner, the assessor allocation grid, the evidence chase list, the certificate register, and the one nobody admits to that reconciles what the LMS says a learner completed against what City & Guilds or Pearson actually certificated. In the quotes our clients have shown us, Aptem and its peers land around £8 to £15 per learner per month depending on volume and modules. Moodle is free until you add hosting, a partner, and the four plugins that break on every upgrade.

Here is the scene that repeats. It is the third week of the funding period. Your compliance lead has a laptop open with the ILR extract on one screen and the LMS attendance report on the other. A learner shows 87 percent attendance in the LMS because the tutor marked the register. But the learner's employer says they were on site that Tuesday, and the workplace evidence upload has a timestamp that contradicts both. The claim for that learner is worth around £4,500 across the programme. Your compliance lead spends ninety minutes on one learner. There are 340 learners in that period. That is not an edge case, it is Tuesday. Across a 400-learner provider we have consistently seen 25 to 40 hours a month go into claim reconciliation that produces zero teaching, zero assessment, and zero new enrolments. Put your own loaded compliance salary against that and it is five figures a year burned on making two systems agree with each other. The real cost is not the hours. It is the clawback when they do not agree and the audit finds it first.

Problem: your funding eligibility rules live in a person's head, not in the system

An eligibility decision at enrolment is a compound rule. Learner age band, prior attainment, residency status, employment status, employer levy position, whether the qualification is on the approved list for that funding stream this year, whether the learner has a prior funded start on a similar programme in the last 12 months, and whether the start date falls inside the contract window. Get one wrong and you do not find out for eight months. Then you get a clawback letter and you repay funding you already spent on tutors.

Moodle has no concept of any of this. It knows courses and completions. Aptem and Maytas do encode funding rules, but they encode the rules the vendor decided to encode, on the vendor's release schedule. When the funding rules change, and they change every August, you are waiting for a vendor patch while your admissions team runs on a PDF of the new rules and their judgement. Meanwhile if you run devolved funding across two or three combined authorities plus an apprenticeship contract plus a commercial arm, you have three or four different rulesets and the off-the-shelf tool models one well and the others badly.

What a custom build does: eligibility becomes a versioned rules engine, not code buried in a form. Each rule is a dated record with a condition, a funding stream, an effective-from and effective-to date. When your compliance lead enrols a learner, the system evaluates every active ruleset and returns a decision plus the reasons: eligible for AEB under rule set 2026-08, not eligible for apprenticeship funding because prior attainment is Level 3 in a related field. That reasoning string gets stored against the enrolment record forever. When the auditor asks in eighteen months why you claimed, the answer is a record, not a memory. When rules change in August, your team edits rules in an admin screen with an effective date, and yesterday's enrolments keep being evaluated under yesterday's rules. This is the single highest-return thing to build first, and it is why we start almost every provider engagement here.

Where AI helps: funding rule documents arrive as 60-page PDFs. We run those through a document extraction pass that drafts candidate rule changes and flags which of your existing rules the new guidance appears to contradict. A human approves every change. It turns a two-day read-and-interpret exercise into a two-hour review. It does not decide anything.

Problem: cohort scheduling and assessor allocation is a spreadsheet that nobody else can run

A multi-site provider running 30 cohorts a term is solving a real constraint problem: room capacity, tutor qualification against the specific unit, awarding body requirements for assessor occupational competence, learner availability against shift patterns, and workplace visit windows for apprentices. Your operations manager solves it in Excel with conditional formatting and a lot of coffee. It works until she is on leave, or until an employer moves 12 learners from nights to days with a week's notice and the whole grid unravels.

Off-the-shelf LMS platforms schedule courses. They do not schedule the human constraints. Moodle will let you set a course start date. It will not tell you that assigning Dave to that assessment breaks the awarding body's independence requirement because he taught the unit. Aptem handles caseload but the allocation logic is caseload-count based, not competence-and-constraint based, so it will happily hand an assessor a caseload that is legal on paper and impossible in geography.

A custom build models the actual entities: tutor with a qualifications matrix mapped to specific units and awarding bodies with expiry dates, sites with room capacity and equipment, cohorts with a delivery pattern, learners with availability windows, employers with sites and postcodes. Then scheduling is a constrained assignment, and the system tells you before you commit that this plan needs one more Level 3 electrical assessor in the north-west from March. The version we ship in first release is usually not a full optimiser. It is a validator plus a suggester: you drag, it tells you what breaks, it proposes three legal alternatives. That gets you most of the value at a fraction of the build. The full optimiser is a phase two conversation and should be, because it only pays off once your data is clean, and your data is not clean yet.

Problem: evidence chasing is a full-time job that produces nothing

For competence-based qualifications the portfolio is the product. Learner uploads a photo of a completed job, assessor maps it to criteria, employer countersigns, IQA samples it. In practice: learner forgets, assessor emails learner, learner replies with a photo attached to an email, assessor downloads it, renames it, uploads it to the LMS, maps it, then emails the employer for sign-off, employer signs a PDF and emails it back. I have watched an assessor spend three hours on admin after a full day of visits.

Moodle assignment submissions do not model criteria mapping across units. SharePoint plus a naming convention is what most providers actually run, and it fails the moment the IQA wants to sample by criterion rather than by learner. OneFile and Aptem do portfolio properly and are genuinely good at it, which is exactly why the honest advice for a lot of providers is to keep them. The break point is when you have evidence that spans multiple awarding bodies with different criteria structures, or when your employers refuse to log into yet another portal.

What a custom build does differently: evidence capture starts on the learner's phone with no login friction, a magic link from an SMS. The photo carries an EXIF timestamp and geotag which becomes your audit trail rather than a hope. AI does two useful things here and they are both narrow. First, it reads the uploaded document or photo and proposes which criteria it evidences, ranked with confidence, and the assessor accepts or corrects with one tap. That turns a five-minute mapping into fifteen seconds and the assessor is still the decision maker. Second, it drafts the chase messages: a nightly job identifies learners whose evidence is behind the expected curve against their planned end date, and sends a specific message referencing the specific missing unit, not a generic reminder. Employer sign-off happens by a signed link that works on a phone, with the countersignature captured as a hashed record with IP and timestamp. Across the providers we have shipped this for, assessor admin time drops materially and, more importantly, evidence lands earlier in the programme rather than in the panic before the gateway.

Problem: the claim, the LMS and the awarding body disagree, and only one of them is right

This is the one that costs real money. Your LMS says complete. Your funding system says in-learning. Your awarding body registration says the learner was never registered for that unit. All three are internally consistent and mutually contradictory. Somebody reconciles by hand. Every month.

The cause is structural: each system has its own idea of what a learner is and what completion means, and the sync between them is either a CSV or a person. Off-the-shelf tools cannot fix this because the fix is not a feature, it is a single source of truth, and no vendor will surrender that position. Every vendor wants to be the master record.

A custom build makes your own database the master and pushes to the others. One learner record with one identity, one enrolment record per programme instance, one immutable event log of everything that happened to it: enrolled, withdrawn, break in learning, restarted, completed, certificated. The funding claim becomes a projection of that event log, not a separate spreadsheet. Awarding body registration goes over their API where one exists, and where it does not, which is often, you build a robust file export plus a reconciliation import that flags every mismatch as an exception queue rather than letting it rot silently. Design the reconciliation as a first-class screen, not a report. Somebody works that queue every morning for ten minutes and the month-end panic disappears. Forecasting sits on the same event log: given current cohort progression velocity, here is the claim value we can expect in each of the next three periods, and here are the 23 learners whose planned end date is now unachievable. That forecast is worth having a finance director's attention on, and it is only possible because the event log exists.

Problem: employers will not use your portal, and that is your problem not theirs

Apprenticeship funding requires employer engagement evidence. Off-the-job hours records, progress reviews, tripartite meetings. The employer's HR (Human Resources) manager has a day job. They will not learn your portal. So your team calls them, transcribes the review into the system, and emails a PDF for signature. That is 40 minutes per review per learner per quarter, and at 300 apprentices it is a headcount.

Every off-the-shelf tool ships an employer portal and nearly every employer portal goes unused, because it asks a person who is not your customer to do work in your system. The custom answer inverts it. Meet the employer where they already are: a link in an email or WhatsApp that opens a single-purpose page with three questions and a signature box, no account. For the progress review itself, the tripartite meeting gets recorded with consent and transcribed, and an AI pass drafts the structured review against your required headings, off-the-job hours discussed, progress against milestones, concerns raised. The tutor edits and submits. The employer confirms by link. What used to be 40 minutes of typing becomes 8 minutes of editing, and the evidence quality goes up because it captures what was actually said rather than what someone remembered to type on Friday.

What this costs and how long it takes

These are Digital Heroes bands from delivery across 2,000+ projects, not vendor pricing.

A focused first release, $60,000 to $130,000, shipping in 12 to 16 weeks. That scope is: learner and enrolment data model, versioned eligibility rules engine, cohort and attendance tracking, evidence capture with criteria mapping, one funding claim export, and a reconciliation exception queue. It runs alongside your existing LMS rather than replacing it. That is deliberate. Content delivery is the one thing Moodle does adequately and replacing it first is how these projects die.

A full platform, $150,000 to $400,000, phased over 6 to 12 months. That adds multi-funder claim logic, awarding body integrations, an assessor mobile app that works offline in a workshop with no signal, employer engagement flows, IQA sampling workflow, and forecasting.

What drives price up in this category, specifically: the number of distinct funding streams you claim against, because each one is a separate ruleset with separate returns and separate audit expectations, and going from one to three roughly adds 30 to 40 percent to the compliance module. The number of awarding bodies, because City & Guilds, Pearson and NCFE range from decent REST to a fixed-width file you SFTP and pray about, and each integration is 2 to 4 weeks. Offline capability for assessors, which sounds minor and is not: proper offline sync with conflict resolution is 3 to 5 weeks on its own and you need it if your assessors work in basements and construction sites. Historical data migration, which is always worse than the estimate because your legacy learner records have four spellings of the same employer name. And any requirement to keep a legacy system running in parallel during transition, which effectively means building the integration twice.

What keeps price down: starting with one funding stream and one site as the pilot, keeping Moodle for content, and accepting file-based awarding body exchange in phase one instead of chasing every API.

Build versus buy: my actual position

Buy, and stop reading, if: you are single-site, under roughly 200 learners a year, running one funding stream, and your qualifications sit with one awarding body. Aptem or Maytas at that per-learner rate is dramatically cheaper than anything we would build, and the vendor absorbs the annual funding rules change for you. That is a real service and it is worth paying for. Buying is also right if your differentiator is your teaching and your employer relationships and nothing about your operating model is unusual. Do not build a worse version of a product that already fits.

Build when these signals show up, and they are concrete. You employ someone whose job title is effectively spreadsheet, and you have had that role for over a year. You have taken a clawback or an audit finding traceable to a data mismatch between two systems. You run three or more funding streams or contract types and the tool models one properly. You have been told a needed change is on the roadmap for more than two release cycles. Your per-learner licence cost across your stack now exceeds roughly $120,000 a year, at which point a $130,000 build pays back inside two years and you own it. Or, the one that matters most: you have a delivery model the market does not have a product for, bootcamp plus employer-sponsored plus commercial in one operation, and the reason you win contracts is exactly the thing your software cannot represent.

The middle path is real and it is where most providers should land. Keep Moodle. Keep your finance system. Build the compliance and evidence spine that sits between them, owns the learner record, and turns your funding claim into a query instead of a ritual. That is the $60,000 to $130,000 first release, and it is where the money leak actually is.

How to choose a developer for vocational training software

Put an enrolment in front of them in the first meeting and ask for the data model, not a wireframe. If they draw learner-course-completion and stop, they are building an LMS and they have not understood your business. The right answer has a programme instance separate from the learner, an immutable event log, break-in-learning as a first-class state, and eligibility as a dated rule evaluation stored with its reasoning. If they have built this before, that model comes out of them in ten minutes. If they have not, it takes them three months and your budget to discover it.

Ask what happens when the funding rules change in August. A team that has lived through it will talk about effective-dated rulesets, replaying historical enrolments under historical rules, and a UI where your compliance lead makes the change without a developer. A team that has not will say they will push an update. Those are different products and only one of them survives a rule change.

Ask about awarding body integration specifically, by name, for your awarding bodies. The honest answer includes the phrase there is no API and here is how we handle that. Anybody who promises clean two-way sync with every awarding body has not tried. What you want to hear is a reconciliation strategy: exception queues, mismatch detection, and a plan for the file formats that will not change in your lifetime.

Ask who owns the code and get it in writing before the first invoice. You should own the repository, the IP, the infrastructure accounts and the data, and you should be able to hand the whole thing to another team without asking permission. Ask for the handover documentation from a previous engagement, redacted. If it does not exist, the code is a hostage situation with a friendly face on it. On a system that holds your funding audit trail, that is not a commercial detail, it is an existential one.