The Document Filing Build Standard

1. What this standard covers, and what it leaves to others

Documents, from every door, and the data entry that goes with them. Each one is counted as it arrives, given one kind, matched to its job, purchase order, customer or supplier by a number printed on it, has the details the business chose typed into that record, and is filed there once. Anything the run cannot do cleanly goes to one exceptions list with a reason and an owner. At the end of the day the run publishes a close: documents in equals filed plus on the list plus duplicates.

What is out of scope, and where it lives instead. Messages, as opposed to documents, belong to the Inbox Triage standard: one shared inbox, who answers each message, response clocks, complaints and acknowledgements. This standard takes documents from every door, not only the inbox, does the data entry into the record, and never answers anything. It reuses two of Inbox Triage’s rules on purpose, and says so: “Every message gets exactly one kind from a closed list” and “A message about a job or a supplier is filed against that record by id”. Here they apply to documents rather than messages, so an office running both keeps one discipline: a closed list and a record id, never a folder.

A supplier invoice this run files is handed on, not paid. It sits on its purchase order or supplier record, where the Invoice Check standard reads it and decides whether it is right to pay. And making two systems agree, the job system and the ledger say, is the Two Records standard. This standard never reconciles two systems. It borrows one rule from Two Records: “The run publishes on schedule with its counts, including the all-clear”, so a day the run did not happen is visible.

What cannot meet it, and what can. Any job system or CRM that can look a record up by its id and accept an attachment against it: ServiceM8, Simpro, Fergus, AroFlo and Jobber for jobs, and Xero contacts for customers and suppliers. Tradify has no public API, so a build cannot file into it directly. And an office that runs on paper with no record numbers cannot meet check 3 until it starts writing a job number on its paperwork. That one change, a job number on every docket and order, is usually the cheapest win in the whole standard.

Is there a ready-made version? Not yet. No product runs this filing run across every door with the exceptions list and the close. So this standard is a Draft, and the build is yours.

2. Every document is counted the moment it arrives

Five doors, and the first thing that happens at each is a count: which door, what time, and a fingerprint of the file. Nothing is filed, set aside or raised that was not counted first, because the close at the end of the day is only as honest as this count.

Then each document gets exactly one kind, from a list the business writes. The list below is a starting point; the business may change it, but it stays closed. A document that is none of them goes on the exceptions list as unknown_kind. It never starts a new folder, because a folder called “Misc” is where documents go to be lost.

3. Each one goes on its record by the number printed on it

Each kind says which printed number finds its record and which details are typed in. The business writes this table once. The build reads it and invents nothing beyond it.

Never by a name, an address or an amount. The photo of the docket with no job number names the supplier and the site, and the job system’s search box would happily offer a job at that address. It might even be the right one. But “might” is how a delivery ends up on the wrong job and gets invoiced to the wrong customer, so the docket goes on the list as no_id and a person who knows says which job. A bare “1055” that fits both job 1055 and order 1055 goes on the list too.

Typing in follows the same caution. Every detail for that kind must read clearly, and a total must equal its lines. If one does not, nothing from that document is typed in: the field is named on the list and left blank, never guessed. And if the record already holds a different value (the job says the quote was $4,800, the signed quote says $4,850), the record keeps its value and both go on the list side by side. A document is never allowed to quietly change what the business already wrote down.

4. The records it keeps, in the shape your developer needs

Five objects. The Arrival is the one most builds leave out, and without it the close cannot add up, because nobody counted what came in.

Arrival                           # written first, append only
  - arrival_id, door (email | scanner | phone_photo |
                      web_form | supplier_portal)
  - arrived_at, file_hash, original   # the file as it came in
  - state (counted | filed | duplicate | on_list)
  - duplicate_of (nullable)

KeyingRule                        # written by the business, per kind
  - kind, document_detail, record_field, must_add_up

Filing                            # unique on (kind, document_number, record_id)
  - arrival_id, kind, document_number
  - record_id                       # the job, order, customer or supplier
  - entered [{field, value, cleared_by}]
  - link -> the original, unaltered
  - filed_at

Exception                         # the one list
  - arrival_id, reason (no_id | two_matches | no_match |
      unreadable_field | does_not_add_up |
      conflicts_with_record | unknown_kind)
  - owner, since                    # the list runs oldest first
  - field, document_value, record_value
  - status (open | cleared)
  - cleared_by, cleared_at, cleared_to

DailyClose                        # one per working day, quiet days too
  - day, arrived, filed, on_list, duplicates
  - open_exceptions [oldest first], published_at

A Filing with no Arrival behind it, or an Arrival that is none of filed, duplicate or on the list at the close, is the defect this standard exists to make visible.

5. The checks, in order

The order is the claim. Counting comes before reading, because the close depends on it. The kind comes before the match, because the kind says which number to look for. The match comes before any typing, and the typing stops at the first doubt.

1. Every document is counted the moment it arrives. Before anything else, each arrival is written down with the door it came through, the time, and a fingerprint of the file. Nothing is filed, set aside or raised that was not counted first.
2. Each document gets exactly one kind from a list the business writes. Supplier invoice, delivery docket, purchase order, signed quote, job sheet or photo, certificate, statement, customer form. A document that is none of these goes on the exceptions list as unknown_kind. It never starts a new folder.
3. It is matched to its record by a number printed on it, never by a name or a guess. The job number, the purchase order number, or the customer or supplier account number printed on the document. No number on it, a number that fits two records, or a number that fits none goes on the exceptions list as no_id, two_matches or no_match.
4. Details are entered into the record only when they read clearly and add up. The details the business chose for each kind (an invoice number and total, a docket's delivery date, a signed quote's amount) are entered only if every one reads clearly and the lines add up to the total. Otherwise nothing from that document is entered, the field is named, and it goes on the list.
5. A value already in the record is never overwritten by a document that disagrees. If the record already holds a different value, both go on the exceptions list side by side as conflicts_with_record, and the record keeps its value until a person decides.
6. The same document arriving twice is filed once. An invoice emailed and also scanned is one document. It is recognised by its kind, its own number and its record, not by the file, because a scan and a PDF of the same page never match byte for byte. The second arrival is noted as a duplicate of the first.
7. The original is kept exactly as it arrived, and linked from the record. The build never edits, renames over or deletes an original. What the record links to is the file that came in, with the same fingerprint it was counted under.
8. Anything that needs a person waits on one list, with a reason and an owner, oldest first. The reasons are a closed list: no_id, two_matches, no_match, unreadable_field, does_not_add_up, conflicts_with_record, unknown_kind. Each exception has an owner. Nothing that needs a person waits anywhere else.
9. The run files and enters details, and never replies, pays, approves or sends. Nothing goes to a customer or a supplier. A filed supplier invoice is left on its record for the Invoice Check standard, which decides on paying. Replies and response clocks belong to Inbox Triage. The only message the run sends is to the owner of an exception, inside the business.
10. The day closes with every document accounted for, published even when it is all clear. At the close, documents in equals filed plus on the list plus duplicates, and the count is published every working day, a quiet day included, so a run that did not happen shows as missing rather than as calm.
11. A person clearing an exception is recorded, and the document then files as normal. Who cleared it, which record they chose and when. The document is then filed to that record and its details entered from what the person decided, with their name against it.
12. For any document, where it came from and what happened to it can be looked up. The door and the time, its kind, the record it was filed to, what was entered from it, whether it was a duplicate, and who cleared it if a person had to.
13. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
14. The pass test passes. On the business's own job system and inbox: a supplier invoice emailed and also scanned is filed once with one duplicate, a docket photo with no job number and a document changed to disagree with the record each wait on the list with their reason, and the day's close adds up.

The exception reasons, a closed list:

6. The day closes with every document accounted for

At the end of each working day the run publishes one short line: how many documents came in, how many were filed, how many are on the list, and how many were duplicates. The first number always equals the other three added together. Under it, the open exceptions, oldest first, each with its reason and its owner.

It publishes on a quiet day too. “Nothing came in, nothing is waiting” is a real answer, and a missing close is a different one: the run did not happen. Silence must never be mistaken for calm, which is the rule this standard borrows from Two Records.

Duplicates are counted, not hidden. The same invoice arriving by email and through the copier is one document, recognised by its kind, its own number and its record. Not by the file: a scan and a PDF of the same page never match byte for byte, so a duplicate rule built on the file alone files every scanned invoice twice.

7. What stays with a person

• ✓Clearing every exception: which job a docket with no number belongs to, which of two values is right, what an unreadable figure says. The run records who cleared it, and then files it.
• ✓Writing the list of kinds and what is typed in for each. The build follows the table; it does not grow it.
• ✓Every reply to a customer or a supplier. That is Inbox Triage's ground, with its own release step.
• ✓Deciding a supplier invoice is right to pay. The run files it where Invoice Check reads it.
• ✓Deleting anything. The run never deletes an original, and neither does any flow it starts.
• ✓How long documents are kept. The run keeps everything; the business sets its own retention.

8. Run it on what you already use

The run lives beside the job system the office already works in. Three ways, all held to the same checks:

• Existing tools only. A shared mailbox, the copier’s scan-to-email, and SharePoint lists for the count, the exceptions and the close. The Microsoft 365 plan lays out the lists and flows.
• A personal dashboard. Hand this page to a coding agent and it builds a small page with today’s count, the exceptions list and a clear button, against the stub until it has to write into the real job system.
• A long-lived bot. A routine that runs through the day as documents arrive, posts each new exception to its owner, and publishes the close at 5pm.

How to run any standard each of these ways is in run a standard anywhere.

9. What your developer builds, and the step that needs care

One step not to hand-roll: landing each document on the one record it belongs to inside the job system the office really uses, entering details there without overwriting anything, and keeping the original exactly as it arrived. Everything else a coding agent builds against the stub in an afternoon.

provider:
  stub:       local.mock_office_run
  production: none                       # scoped build, not a product

the stub                             # local.mock_office_run
  - a morning's arrivals through five doors, with fingerprints
  - jobs, purchase orders, customers and suppliers by id
  - a search box and a file store, so a shortcut shows
  - one exceptions list, and a person who clears it next day

production: your own systems
  - the job system or CRM: look up by id, attach, enter a field
  - the real inbox, copier and phone photos
  - quoted as a scoped build; no hosted product runs this

stays local                          # yours, and the standard
  - counting, kinds, matching, the exceptions list, the close
  - clearing an exception, which is a person's, always

cannot meet the standard
  - a job system with no way to attach a file by record id
  - paperwork with no job, order or account number on it

A vendor selling document capture is usually selling the reading. Ask them three things: what happens to a docket with no job number, what happens when the document disagrees with what the job already says, and where the count of what arrived today is published.

10. A checklist to hold any build or supplier to

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. Every document is counted the moment it arrives. Before anything else, each arrival is written down with the door it came through, the time, and a fingerprint of the file. Nothing is filed, set aside or raised that was not counted first.
• ✓2. Each document gets exactly one kind from a list the business writes. Supplier invoice, delivery docket, purchase order, signed quote, job sheet or photo, certificate, statement, customer form. A document that is none of these goes on the exceptions list as unknown_kind. It never starts a new folder.
• ✓3. It is matched to its record by a number printed on it, never by a name or a guess. The job number, the purchase order number, or the customer or supplier account number printed on the document. No number on it, a number that fits two records, or a number that fits none goes on the exceptions list as no_id, two_matches or no_match.
• ✓4. Details are entered into the record only when they read clearly and add up. The details the business chose for each kind (an invoice number and total, a docket's delivery date, a signed quote's amount) are entered only if every one reads clearly and the lines add up to the total. Otherwise nothing from that document is entered, the field is named, and it goes on the list.
• ✓5. A value already in the record is never overwritten by a document that disagrees. If the record already holds a different value, both go on the exceptions list side by side as conflicts_with_record, and the record keeps its value until a person decides.
• ✓6. The same document arriving twice is filed once. An invoice emailed and also scanned is one document. It is recognised by its kind, its own number and its record, not by the file, because a scan and a PDF of the same page never match byte for byte. The second arrival is noted as a duplicate of the first.
• ✓7. The original is kept exactly as it arrived, and linked from the record. The build never edits, renames over or deletes an original. What the record links to is the file that came in, with the same fingerprint it was counted under.
• ✓8. Anything that needs a person waits on one list, with a reason and an owner, oldest first. The reasons are a closed list: no_id, two_matches, no_match, unreadable_field, does_not_add_up, conflicts_with_record, unknown_kind. Each exception has an owner. Nothing that needs a person waits anywhere else.
• ✓9. The run files and enters details, and never replies, pays, approves or sends. Nothing goes to a customer or a supplier. A filed supplier invoice is left on its record for the Invoice Check standard, which decides on paying. Replies and response clocks belong to Inbox Triage. The only message the run sends is to the owner of an exception, inside the business.
• ✓10. The day closes with every document accounted for, published even when it is all clear. At the close, documents in equals filed plus on the list plus duplicates, and the count is published every working day, a quiet day included, so a run that did not happen shows as missing rather than as calm.
• ✓11. A person clearing an exception is recorded, and the document then files as normal. Who cleared it, which record they chose and when. The document is then filed to that record and its details entered from what the person decided, with their name against it.
• ✓12. For any document, where it came from and what happened to it can be looked up. The door and the time, its kind, the record it was filed to, what was entered from it, whether it was a duplicate, and who cleared it if a person had to.
• ✓13. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓14. The pass test passes. On the business's own job system and inbox: a supplier invoice emailed and also scanned is filed once with one duplicate, a docket photo with no job number and a document changed to disagree with the record each wait on the list with their reason, and the day's close adds up.