For the ops manager at independent IT, healthcare, and trades certification training providers and bootcamps that pre-buy certification exam vouchers in cohort batches: VoucherLedger tracks every voucher — its assignment, its expiry, and its rules — keeps the chase to each learner on record until the exam is booked and sat, reassigns before expiry, and produces the pass and outcome record funders and accreditors ask for. Unused vouchers are forfeited at expiration — this ledger exists so none expire unnoticed.
How it works
- Add vouchers singly or as a batch — vendor and exam, quantity, unit cost, and issue and expiry dates
- Track every voucher through Unassigned, Assigned, Booked, and Sat (Pass or Fail), with reassignment history preserved
- Work the expiry radar sorted soonest-first — live value at risk is the unassigned and unsat vouchers multiplied by unit cost
- Keep the learner chase log against every learner who has not yet booked and sat
- Reassign a voucher before expiry when its learner will not use it, with the reassignment kept in the voucher's history
- Enter each outcome by hand, and produce the cohort outcome record — assigned, booked, sat, and passed counts, with sat and pass rates — exported as CSV for funders
Every voucher — tracked from purchase to outcome
Vouchers are added singly or as a batch — vendor and exam, quantity, unit cost, and issue and expiry dates — and from that moment every voucher is tracked: its assignment, its expiry, and its rules, held in the provider's own rule notes (see the vendor-rules section below).
Every voucher sits in exactly one state, and its reassignment history is preserved as it moves:
- Unassigned
- Assigned
- Booked
- Sat (Pass or Fail)
The chase — to booked and sat, on record
Against every learner who has not yet booked and sat, VoucherLedger keeps the learner chase log: the record of the chase, learner by learner, until the exam is booked and sat. The log is the provider's own record of the chasing its staff does.
The chasing itself is the provider's, done manually today: VoucherLedger does not message learners, and there is no live chase sending behind the log. That statement is carried again in the honest state below, because it does not change.
Expiry radar — and reassignment before expiry
The expiry radar is sorted soonest-first, so the vouchers closest to expiring are the ones worked first. Its live value at risk counts what would be lost: the unassigned and unsat vouchers, multiplied by unit cost. Unused vouchers are forfeited at expiration — this ledger exists so none expire unnoticed.
When a voucher's learner will not use it, the voucher is reassigned before expiry, and the reassignment is kept in the voucher's history. Reassignment in the ledger records the provider's own reassignment of a voucher; what any testing channel permits is a matter for the provider's own notes — VoucherLedger asserts nothing about it.
Vendor rules — only the provider's own notes
The rule notes on a voucher are the provider's own free-text, written by the provider from its own records. VoucherLedger asserts no vendor rules: it ships with no vendor-rule knowledge of its own, and it states no testing vendor's rules anywhere — not on this page, and not in the product.
Rule data is maintained per testing channel from the provider's own records, channel by channel, as the provider supplies it. That is why the application below asks which testing channels a provider uses, in the provider's own words: the product holds no vendor data of its own to ask against.
The outcome record — what funders and accreditors ask for
Each cohort closes with its outcome record: assigned, booked, sat, and passed counts, with sat and pass rates, exported as CSV for funders — the pass and outcome record funders and accreditors ask for. The record reports the cohort's own entered outcomes; it promises no rate and no result.
Outcomes are hand-entered today. There is no automatic outcome feed from any testing vendor — no vendor returns outcome data to VoucherLedger automatically, and no such integration has been built. Every outcome in the record is one the provider entered by hand.
Where it stands — the honest state
VoucherLedger is forming its first provider pilot group now. The door below is a provider pilot application — applying starts a pilot conversation; it does not create an account, and it is not a sign-up for a running service.
Live learner chase sending does not exist. VoucherLedger sends no chase messages to learners today and contacts no learner; the provider chases learners manually today, and what the product holds is the chase log — the record of that manual chasing.
Outcomes are hand-entered today, as stated above: no automatic outcome feed from any testing vendor exists, and none has been built. Until an integration exists, outcome entry stays by hand.
Vendor rules live in VoucherLedger only as the provider's own notes. The product asserts no vendor rules of its own, and vendor-rule data maintained per testing channel — sourced from providers' own records — is a standing commitment, not a shipped library.
No price has been set. A price range exists in our market research as a hypothesis; it has not been validated and it has not been decided, so no price is shown here and there is nothing to buy on this page.
Provider pilot application
This is a provider pilot application — an application to join VoucherLedger's first provider pilot group, not an account sign-up and not a purchase. Tell us who to reach, your provider, and how many vouchers you manage in a year. If you like, tell us the testing channels you use, in your own words — VoucherLedger holds no vendor data of its own — and how you track vouchers and chase learners today. We will be in touch about the pilot group.