Data Quality Check
What the check looks for, how findings are acknowledged, and what blocks approval.
Every upload runs through a quality check before anything is stored. If the check fails on a fund-level ingest, nothing is written and the platform says so — you never end up with half a file in the database.
The four states
Quality status is shown the same way everywhere in the platform:
| State | Meaning | Can you approve? |
|---|---|---|
| Clean | Checked, nothing found | Yes |
| Warnings | Checked, findings that need acknowledging | Yes, once each finding is acknowledged with a reason |
| Errors | Checked, findings that block | No |
| Not run | No check has been run — deliberately distinct from a failed check | No |
"Not run" is modelled as an honest state in its own right. A file nobody has checked never masquerades as a file that passed.
Acknowledging findings
Warnings are acknowledged individually, each with a recorded reason — there is no blanket "accept all". Each acknowledgement is stored against the exact quality-check run the reviewer was looking at, together with who accepted it and when, and past runs stay visible for audit.
Sign-off runs a fresh check at the moment of approval and records acknowledgements against that run, so a decision can never be attached to a stale result. If the data has gone dirty since an earlier clean run, approval is refused.
What always blocks
Two findings can never be acknowledged away:
- A currency mismatch. Mixed currencies are never summed silently. A missing declared currency is a warning you can acknowledge; an actual mismatch is a hard block. Mixed currencies are also detected across contributing companies during roll-up.
- A partly-read file. If the parse reports truncation, a blocking error is injected and carried forward into the approval step, so a partially-read file can never be approved or published as if it were complete.
Fixing problems
The primary route is to fix the source spreadsheet and re-upload it — the platform is not meant to become the place your numbers get edited.
Where that is not practical, a flagged value can be corrected in-app before approval with a mandatory reason and a full audit trail. See correcting a flagged value.
Re-running a check
A stored submission can be re-checked on demand after a correction, and approval always re-checks regardless.
Help from Nia's reference library
The KPI reference library also works as a data-cleaning source:
- A submission label that does not map to your dictionary but matches a reference alias produces a did-you-mean suggestion, with the reference name and unit.
- A fund KPI whose unit disagrees with the reference list raises an advisory.
Next step
Approve the data, then generate the report.