Topic
FIS and Submit Learner Data: the submission workflow
When to validate locally, when an actual submission is needed, what each report tells you, and how resubmission works within a collection window.
Enough detail to do the job and hold a sensible conversation with MIS or Finance.
- Official requirement: Stated by the official funding document named in the sources for this page.
- FEFunding explanation: Our plain-English explanation. Helpful, but the official document is the rule.
- Worked example: An illustration of how the rule applies in one situation. Not a universal rule.
- Recommended good practice: Operational advice from FEFunding. Not itself a funding requirement.
Two tools, two jobs
The Funding Information System runs on your own machine. It checks your file and shows you what it would earn, without sending anything anywhere.
Submit Learner Data is the service you actually upload to. It checks the file again and produces the official reports for the period.
Use the local tool whenever you want to know something without committing to it: checking the effect of a data change, testing after a system upgrade, or answering a finance question mid-period.
Use the service when you are making the return for the period. The two run the same validation rules, so what passes locally passes on submission.
The local tool applies the published rule set for the funding year and produces the funding reports from the file without submitting. It is the safe place to test a change before it reaches a live return.
The service validates on upload, produces the validation error report and the funding reports, and records the submission against the collection period.
When a submission is and is not needed
You submit once per collection period, by the deadline. You can usually submit more than once inside the window, and the last valid one before the deadline is the one that counts.
You do not need to submit just to check something. That is what the local tool is for.
The practical consequence is that there is no reason to wait. Submit early, read the reports, fix what the reports show, and submit again. That converts the deadline from a cliff edge into a checkpoint.
Colleges that submit once, late, are the ones that discover systemic problems with no time to fix them.
Confirm the collection window and deadline for each period against the data collection timetable for the funding year. The timetable is the authority; anything else is a convenience.
Retain each submission's file, validation output and funding reports. Where more than one submission is made in a window, the retained set for the final submission is the record of the period.
Reading the reports you get back
Two kinds of report come back. One lists everything that failed validation. The other shows what your data earned.
Read both. The first tells you what is broken; the second tells you whether what is not broken is right.
The funding reports are what Finance reconciles against. Reading them yourself first, before Finance does, means you explain the movement rather than being asked about it.
Compare each period against the last at total level first. A movement with the same learner count is a rate or code issue; a movement with a different count is a population issue.
Each ILR return is a complete restatement of the funding year to date, not an increment. Every return replaces the last, which is why an error introduced late can change earnings already reported.
Build a standing period-on-period comparison of the funding reports by funding model and by curriculum area. It turns the monthly reconciliation from an investigation into a check.
Where the reports available differ by stream, note which report Finance uses for each stream in the funding map so the reconciliation is repeatable by anyone.
Worked examples
Worked example
A calm collection window
A well-run monthly routine for a college with several thousand learners.
- Day 1 of the window. Generate and validate locally. Group errors by rule.
- Days 2 to 4. Fix causes in the source system. Regenerate and revalidate.
- Day 5. Submit. Read the validation output and the funding reports.
- Days 6 to 8. Work the remaining issues and the funding reconciliation.
- Before the deadline. Resubmit with the corrections. Circulate the reconciliation.
The deadline is a formality rather than an event.
An illustrative routine. Fit it to your own collection window and team capacity.
Common pitfalls
Treating the local tool as optional
What goes wrong: Validation happens for the first time on submission.
Consequence: Problems are discovered when there is no time to fix their causes.
Prevention: Validate locally at the start of every window, without exception.
What this means for your role
MIS or ILR officer
The window is a working period, not a deadline.
- Validate on day one. Submit early. Resubmit after corrections.
See it play out
Sources
These are the official documents this page rests on. Where a figure, a deadline or an exact rule matters, the document is the authority and this page is the explanation.
Content reused from GOV.UK is Crown copyright, used under the Open Government Licence. FEFunding is not endorsed by the Department for Education.