Assisted data entry: pre-filled from the documents, checked before approval

I fill the fields I can justify and leave empty the ones I cannot.
On a supplier record to be created: I have 7 fields out of 12, each taken from a document you hold — company name and identifier from the quotation, address and code from the bank details, contact from the covering email.
The other 5 stay empty, and I say why: the activity code appears on no document; two fields belong to your internal taxonomy, which the documents do not know; two are management choices.
The activity code I go and fetch rather than guess: inferred from the company name it would be right nine times out of ten, and the tenth is what costs you — a rejected payment order, a misfiled supplier, and nobody left to remember the field was guessed. So I asked the supplier for it, in the reply to their quotation, together with the two other missing taxonomy fields: the record will complete itself when they answer, and you will retype nothing.
Every filled field carries its document and its line, and you approve the record whole or field by field.
The gain is not that I type for you: it is that you no longer open four documents to fill twelve boxes. supplier-record_7-of-12.pdf7 fields justified · 5 left empty
⛓ Source · quotation of 22/07, bank details, covering email of 24/07

Then you approved, and the system will say so. I do not claim to prevent that — no tool can, and a tool claiming otherwise is selling you a guarantee it cannot honour.
What I can do instead: make looking fast. Every filled field shows the document and line it came from, on hover. Checking twelve fields takes a minute when the source is there, and five when the documents have to be reopened.
And make looking necessary where it counts: fields that carry risk — an IBAN, an identifier, an amount — are never pre-filled silently. They are pre-filled and marked as to be checked, and the record cannot be approved as a block until they have been seen.
That is the only place where I slow you down on purpose, and it is where an error costs most: a wrong IBAN surfaces at the first payment, not before. fields-to-check_why.pdf3 families of field · never approved as a block
✎ Framework · risk-bearing fields to be defined with the department

Inconsistencies are flagged, never arbitrated — and the flag carries both values, not a conclusion.
What I compare: every field I prepare is checked against all the documents in the file that carry it. Across the 1,840 records prepared this quarter: 147 inconsistencies flagged, that is 8 % — a floor area of 84 m² on the property tax notice and 91 m² on the attached plan; a married name on the identity document and a birth name on the certificate; a tenancy start date of 1 March on the contract and 15 March on the insurance certificate.
Missing documents are flagged the same way: 212 records carry the field made mandatory in March with no migration of existing data, and no document in the file supplies it. I do not invent it and I do not fill it with “none”: the field stays empty, the record carries the note “document absent”, and the 212 are handled in one pass rather than as 212 alerts that would wear attention down.
What a flag contains: both values, the document and the page each came from, the date of each document — and nothing else. Choosing between two official documents is casework: it belongs to the officer, who settles it in ten seconds with both documents open, instead of ten minutes hunting for them.
What that gives back: tracing the origin of a discrepancy took 12 minutes; the flag opens it at the right page. Across 147 inconsistencies a quarter, more than 107 hours given back over the year, rounded down.
The figure that does not flatter me: of my first 300 flagged inconsistencies, 96 were wrong — 32 %, and your administrators started closing them without reading, which is the worst possible outcome. All of them compared a value against a document older than the file's last update: I was comparing values without comparing their dates. I now compare against the most recent document carrying the field, and I print the date of both: over the next 900, the wrong ones fell to 6 %, and your administrators open them one by one again.
⛓ Sourced · 147 inconsistencies flagged across 1,840 records, 212 empty fields handled in one pass, 32 % wrong down to 6 %

It means one building counts as four in your reports.
The four spellings: with "avenue", with "av.", with the full name, and a fourth where the number runs into the street name.
What that produces: a per-building cost statement showing four small lines instead of one real one. Nobody sees what this building actually costs, and it is more than any single line suggests.
What I propose: one reference spelling, with the other three attached — deleting nothing. A deleted record breaks past reconciliations; an attached one preserves them.
What I have prepared so the choice takes one minute: for each of the four spellings, how many records carry it, which systems are involved, and what re-keying it would cost if that one is kept. Two of the four match your addressing standard, and one of those two already covers 71% of the records. The reference spelling is signed by the department that owns the reference data — it is a taxonomy decision, it holds across every system at once, and it is now taken on a table rather than in six months on a hunch.
How many cases like it: 147 addresses have more than one spelling, 31 of them more than three. 147-addresses_multiple-spellings.pdf147 addresses · 31 above three
⛓ Source · address reference data, finance system, schools system

They all share one cause, and that is good news.
What they have in common: all 38 appeared at the moment a case moves from one department to another. The first department creates the record, the second cannot find it — because it searches on a field the first left empty — and creates it again.
The field at issue: the external identifier. It is optional at creation, and it is the only one the second department knows how to search on.
What that gives: two records, two histories, and a case progressing on one while the documents arrive on the other.
Two ways to fix it, and the second is better: I can flag each duplicate as it is created — useful, but a plaster. Or you make the external identifier mandatory at creation, and all 38 disappear at once.
My value here is not catching 38 duplicates a month: it is showing you that 38 duplicates a month turn on one optional field. 38-duplicates_one-cause.pdf38 duplicates · 1 optional field
✎ Proposal · one field to make mandatory — the decision is the department's

We sort them before handling them, because the 212 are not alike.
What I looked at: for each one, whether the missing value exists elsewhere in your data.
· 128 records: the value is in another system, on the same record. I can propose it, with its source.
· 51 records: the value is on a document in the file. I can propose it, with the line.
· 33 records: the value exists nowhere. It has to be asked for, or the record has to be closed.
The 33 with no value I do not leave as they are either: a default value would be worse than the blank — a field made mandatory in March and filled with "not stated" is not filled, it is hidden, and the next person will believe it is. So I have written the 33 requests, one per record, addressed to the department holding the information, and flagged the 9 records with no activity for two years, which are to be closed rather than completed.
What I propose: a list of 179 proposals to approve in batches of ten, with the 33 handled separately, because they call for a decision and not an approval. 212-records_179-values-found.pdf128 + 51 found · 33 to decide
⛓ Source · 212 records, systems reconciled, documents in the files

What allows the path to be retraced, and nothing that describes anyone.
What is kept: the proposal made, the document and line justifying it, the date, and what became of it — approved, amended or discarded.
What is not kept: no statistics per officer, no individual acceptance rate, no approval time per person.
Why this is written here: a tool measuring how many proposals each officer accepts would produce the exact opposite of what is wanted. An officer who knows they are measured approves faster and looks less — and the tool would then have degraded the quality it claims to serve.
What the monthly summary does contain: the fields where my proposals are most often amended. Those are the ones I get wrong, or the ones whose rule changed without my knowing — in either case it is a setting to fix, not a person to see. what-is-kept.pdf4 items kept · 3 never kept
✎ Framework · retention periods to be set by the authority