Data Quality Check
What the check looks for, how findings are acknowledged, and what blocks approval.
Not available in the current release. LP Reporting is switched off for all organisations while it is finished. The screens described on this page are not reachable yet — the navigation shows them under "Coming soon", and opening one directly returns you to your workspace home.
This documentation is published now so you can see what is coming and tell us what matters most. Nothing here describes behaviour you can use today.
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.