Reference deployment · R-04
Invoice capture and coding for an SME finance team
A four-person finance function re-typing about 700 supplier invoices a month from PDFs and photographs. A self-hosted extraction pipeline that proposes the fields and the coding, and a person who approves every one of them before anything is paid.
- Source
- Designed by us against a stated scenario. 0 of 22 compliance issues are anchored in a fetched instrument.
- Verified
- 24 Aug 2026
- Confidence
- Low
| Parameter | Declared value |
|---|---|
| Scenario | Hong Kong trading company, 120 staff, finance team of 4, ~700 invoices a month |
| Industry | Accounting |
| Organisation size | 120 employees — Medium (50–249) |
| People using the system | 6 |
| Technical capability | Basic |
| Jurisdictions | Hong Kong |
| Data residency required | Hong Kong |
| Data types declared | invoices, receipts, scanned documents, supplier data, financial records, personal data |
| Languages | English, Traditional Chinese, Simplified Chinese |
| Delivery assessed | self hosted |
01Problem
Supplier invoices arrive by email as PDFs, as photographs taken on a phone, and occasionally on paper. Someone re-types the supplier, the invoice number, the date, the line items, the tax and the total into the accounting system, then codes it to a cost centre.
At roughly 700 a month across four people this is most of a full-time role, and it is the role most likely to be interrupted. Errors are found at reconciliation, weeks later, when the invoice is hard to find again.
The team has been sold "AI invoice automation" twice and both times the demonstration worked on clean single-page English invoices. Their invoices are not that.
02Constraints
- 01A person approves every invoice before paymenthard — eliminates optionsNon-negotiable and not a limitation of the technology. Payment authority stays with a human, and the system’s output is a proposal on a screen.
- 02Financial records and supplier data stay on company hardwarehard — eliminates optionsInvoices carry counterparty commercial terms and, on a small-supplier invoice, personal data. The company’s position is that these are not sent to a third party for processing.
- 03Every extracted field is traceable to the pixels it came fromhard — eliminates optionsAn approver who cannot see where a number came from cannot approve it, and an auditor asking about a figure eighteen months later needs the same trail.
- 04Three languages and a wide format spreadshapingEnglish, Traditional and Simplified Chinese, across a few hundred supplier templates, some photographed at an angle.
- 05No engineering teamshapingOnce running, the system is operated by the finance team. Adding a supplier template must not require code.
03Recommended solution
A self-hosted extraction pipeline with a queue, an approver, and a stored original
Extraction is the smallest part of this deployment. The pipeline that matters is: receive, store the original, extract, propose a coding, queue for approval, post on approval, and keep every step joined to the document image.
The model reads; it does not decide. Confidence below a threshold routes to the queue with the field highlighted rather than being quietly accepted, and a supplier the system has not seen before always goes to a person.
The exception path is where the deployment succeeds or fails. Aim for a first-pass rate that is honest — a substantial majority of invoices proposed correctly, with the rest arriving in a queue that is faster to clear than re-typing was.
Component
Why — assessment
- 01Intake and archivePaperless-ngxGives the pipeline a document store with the original preserved, which is what makes an approval traceable and an audit answerable.
- 02Document conversionDoclingConverts mixed PDFs, scans and photographs into structured text with layout retained — the layout is how a total is distinguished from a line item.
- 03ExtractionvLLM with constrained decoding to a fixed schemaStructured output means the pipeline receives fields it can validate rather than prose it has to parse. A field that fails validation goes to the queue.
- 04Orchestrationn8nThe finance team can see and change the flow — a new supplier rule, a different approver — without an engineer.
- 05Record storePostgreSQLOne place holding the extraction, the confidence, the approver, the timestamp and the link to the stored original.
04Architecture
External data transfer
External data transfer: NONE
No edge in this design crosses the boundary drawn below. Boundary: COMPANY NETWORK.
Components
- Finance team (approvers) — people
- Paperless-ngx (originals) + Docling (conversion) — storage
- Original invoice images and PDFs — storage
- n8n (intake → extract → approve → post) — application
- PostgreSQL (extractions, approvals, audit trail) — database
- vLLM with constrained decoding — inference server
- Accounting system (on premise) — internal system
- Open-weights instruct model (4-bit) — model
- Company GPU server (24 GB) — hardware
Connections
- Finance team (approvers) to n8n (intake → extract → approve → post) — HTTPS (confidential data)
- n8n (intake → extract → approve → post) to PostgreSQL (extractions, approvals, audit trail) — chats, users, settings (personal data)
- n8n (intake → extract → approve → post) to vLLM with constrained decoding — prompt (confidential data)
- vLLM with constrained decoding to Open-weights instruct model (4-bit) — loaded weights
- Open-weights instruct model (4-bit) to Company GPU server (24 GB) — GPU memory
- vLLM with constrained decoding to Company GPU server (24 GB) — GPU memory
- n8n (intake → extract → approve → post) to Accounting system (on premise) — approved invoice (confidential data)
External data transfer · NONE
- No edge in this design crosses out of the company network.
- Model weights are downloaded once at setup; extraction runs with no outbound connection thereafter.
- The accounting system this pipeline posts into already runs on the same network: it is inside the company-network boundary, and an approved invoice never crosses it.
- Nothing is posted to the accounting system until a named person has approved it on screen.
05Compliance
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
22 of 40 rules fired for this scenario, across Hong Kong, China (mainland).
China
Classify the data before deciding where it may go
The Data Security Law establishes a data classification and grading protection system, with heavier duties attaching to important data. Until the corpus has been classified, it is not possible to say whether important data is in it — and every downstream decision about processing location and outbound transfer depends on that answer.
- Required checks
- Classify the repositories in scope against the applicable sector catalogue before indexing.
- Record the classification and who made it, because it will be asked for.
- Re-check when the corpus expands; the classification is about content, not about the system.
- Technical controls
- Carry the classification label through ingestion so it constrains where a document may be processed.
Human review required — take this to your counsel
A personal information protection impact assessment, kept for three years
PIPL requires an impact assessment before processing sensitive personal information, using personal information for automated decision-making, entrusting processing or providing information to another handler, and sending it abroad. The assessment and the processing record must be retained. An AI deployment usually triggers more than one of these at once.
- Required checks
- Run one assessment covering every trigger the deployment engages, rather than several partial ones.
- Record the retention period for the assessment itself.
- Vendor questions
- Will you provide the technical detail we need to complete the assessment?
Human review required — take this to your counsel
Settle whether the generative AI measures reach this service
The Interim Measures apply to using generative AI technology to provide content-generation services to the public inside China. Services with public-opinion attributes or social mobilisation capability must undergo a security assessment under the applicable rules. An internal enterprise assistant is normally outside that scope, but the scope question has to be settled and recorded, because the answer drives filing and assessment obligations.
- Required checks
- Decide whether the service is provided to the public in China, and write down why.
- If it is, establish whether it has public-opinion attributes or social mobilisation capability.
- Where either applies, plan for the security assessment and algorithm filing lead time.
- Vendor questions
- Have you completed the security assessment and algorithm filing for your service in China?
Human review required — take this to your counsel
PIPL — a basis, and a notice that matches what you are doing
PIPL applies to processing the personal information of natural persons inside China, and Article 3 extends it to processing outside China aimed at offering products or services to people in China or analysing their behaviour. Processing needs a statutory basis and a notice that truthfully describes the purposes, methods, categories and retention period. An AI feature added to an existing system usually changes all four, which means the notice changes too. A separate set of simplified measures for handlers of fewer than 100,000 individuals’ personal information takes effect on 1 September 2026 and was not yet applicable when this page was reviewed.
- Required checks
- Rewrite the notice for the AI processing rather than appending a sentence to the old one.
- Identify the statutory basis; consent is common but not the only route.
- Check whether the organisation would fall inside the small-handler simplified measures once they apply.
Labelling AI-generated content, explicitly and implicitly
The labelling measures, in force since 1 September 2025, require both an explicit label visible to the user and an implicit label added to the file metadata of generated content, which is not readily perceptible. Article 11 requires labelling to conform to the mandatory national standard, and distribution platforms carry verification duties of their own.
- Required checks
- Establish whether output reaches the public, which is what brings the measures into play.
- Check what the platform you publish through requires, in addition to what you do.
- Vendor questions
- Does your service emit content metadata or watermarks that satisfy the implicit labelling requirement?
- Technical controls
- Add the visible label at render time and the embedded label at generation time; they are separate obligations.
Cross Cutting
Self-hosting moves the security obligation to you
Keeping data on your own hardware answers the transfer question and creates an operations question. Patching, backups, key management, monitoring and incident response are now yours, and an unpatched inference server on the office network is a worse outcome than a well-run vendor.
- Required checks
- Name the person responsible for patching each component, and the cadence.
- Confirm backups exist, are encrypted, and have been restored at least once.
- Confirm there is an incident response path that includes this system.
- Technical controls
- Encrypt at rest and in transit, including between the application and the inference server.
- Centralise authentication through the existing identity provider rather than local accounts.
- Keep an audit log of who queried what, and protect it from the people it records.
- Subscribe to security advisories for each component and track upgrade lag.
Being able to reconstruct a decision months later
The question that arrives after a complaint is what the system was shown and what it produced on a particular day. Models change, prompts change, and indexes are rebuilt, so the answer has to be recorded at the time. Without it, the only available response is that the output cannot be reproduced.
- Required checks
- Decide what is recorded per interaction: model and version, prompt template version, retrieved document ids, output, reviewer and outcome.
- Set how long those records are kept, balanced against the retention duties that also apply to them.
- Vendor questions
- Does the vendor pin model versions, and how much notice is given before a model is retired or changed?
- Technical controls
- Version prompt templates in source control and log the version used.
- Log the model identifier and version returned by the provider, not the one you requested.
Confidentiality duties bind independently of data protection law
Material can be entirely free of personal data and still be the material a contract stops you disclosing. Client retainers, non-disclosure agreements, supplier contracts and common-law duties are the usual sources, and several of them require consent before a third party processes the material at all — which a model API call is.
- Required checks
- Review the confidentiality clauses in the contracts covering the material going into the system.
- Identify any contract requiring notice or consent before a subcontractor processes the material.
- Decide whether the deployment needs a confidentiality carve-out negotiated into new contracts.
- Vendor questions
- Will the vendor accept a confidentiality undertaking beyond its standard terms?
- Which staff at the vendor can access customer content, under what controls?
- Technical controls
- Segregate the most sensitive corpora into an index that the general assistant cannot reach.
Human review required — take this to your counsel
An AI deployment creates new copies of the data
Vector indexes, prompt logs, completion caches, evaluation datasets, fine-tuning checkpoints and backups are all copies of the source material in places the existing retention schedule does not mention. Deletion requests are the moment this is discovered, because deleting the source document does not delete its embedding.
- Required checks
- List every store the deployment creates and add each to the retention schedule.
- Establish how a deletion request propagates to the index, the caches and the logs.
- Establish how long backups keep material that has been deleted from the live system.
- Vendor questions
- What does the vendor retain, where, and for how long after we delete our copy?
- Technical controls
- Store the source document id with every embedding so deletion can cascade.
- Set time-to-live on prompt and completion logs rather than relying on manual cleanup.
Who can reach the model, the index and the weights
A self-hosted stack has three access surfaces that are easy to leave open: the inference endpoint, the vector index, and the weights on disk. Retrieval also carries an authorisation problem an ordinary application does not have — the index must not return a document to someone who could not open it in the source system.
- Required checks
- Confirm the inference endpoint is not reachable from outside the network and requires authentication.
- Confirm retrieval filters by the requesting user’s permissions, not only by relevance.
- Confirm who can read the model files and the index volume at the operating-system level.
- Technical controls
- Bind the inference server to a private interface and put an authenticating proxy in front of it.
- Carry document-level access control into the index and enforce it at query time.
- Encrypt the volume holding the weights and the index, and restrict it to the service account.
- Rotate API keys and keep them out of client-side code and container images.
What ends up in a prompt, and where it goes next
Even with inference inside the network, prompts and retrieved context accumulate in logs, traces and caches, and system prompts can often be extracted from the output. The leak path is internal rather than external, but it is still a copy of the source material in a new place.
- Required checks
- Write down which categories of information may be entered into a prompt, and tell people.
- Establish what the system prompt contains and whether disclosing it would matter.
- Establish which shadow tools staff are already using; the policy has to name the permitted ones.
- Vendor questions
- Are prompts and completions retained, for how long, and can retention be set to zero?
- Are prompts used for abuse monitoring, and if so who can read them and for how long?
- Technical controls
- Redact or block high-risk patterns before the prompt leaves the application.
- Keep prompt and completion logs out of general-purpose observability tools.
- Set an explicit retention period on prompt logs and enforce it.
Rights in the material you index and in what the model produces
Two separate questions get conflated. First, whether you hold the rights to index, embed or fine-tune on the material you feed the system — licensed databases, customer documents and third-party reports often say you may not. Second, whether generated output that closely reproduces protected work creates exposure. Both are contract and copyright questions that vary by jurisdiction, and neither is answered by the model licence.
- Required checks
- List the corpora going into the index and confirm each one’s terms permit machine processing and storage of derived embeddings.
- Check whether any source is a licensed third-party database with an anti-scraping or anti-derivative clause.
- Decide, and write down, who owns the output in your customer contracts.
- Vendor questions
- Does the provider offer any indemnity for third-party intellectual-property claims arising from output, and what conditions attach to it?
- Technical controls
- Record the source document for every retrieved passage so an output can be traced to what it was grounded on.
A component carries a strong copyleft licence
Paperless-ngx licence is licensed under a strong copyleft licence. Internal use normally carries no distribution obligation, but shipping a modified binary or an appliance to anyone outside the company does.
- Required checks
- Read the actual LICENSE file in the version you deploy — a project can relicense between releases, and an SPDX field in a package registry is not the licence.
- Record whether you modify the component or run it unmodified; the obligation usually turns on that.
- If you modify it and expose it to users, plan for making the corresponding source available.
- Check for a commercial or dual licence if the copyleft obligation does not fit your plans.
- Vendor questions
- If a supplier packages this component for you, ask which licence governs their build and what they publish.
- Technical controls
- Generate a software bill of materials at build time and fail the build on an unexpected licence.
- Keep your changes in a clearly separated patch set so that the source you would have to publish is easy to identify.
Hong Kong
DPP4 — all practicable steps to protect the data
DPP4 requires all practicable steps to protect personal data against unauthorised or accidental access, processing, erasure, loss or use, including where a data processor holds it. For a retrieval system that normally means access control that mirrors the source repository, encryption at rest and in transit, and an audit log — and it is the principle the Commissioner reaches for after a breach.
- Required checks
- Confirm retrieval cannot return a document to a user who could not open it at source.
- Confirm encryption at rest for the index, the logs and any model artefacts.
- Confirm there is a tested route to detect and respond to unauthorised access.
- Vendor questions
- What security certifications do you hold, and can we see the current report rather than a badge?
- Which of your staff can access customer content, and under what controls?
- Technical controls
- Enforce document-level permissions at query time, not only at ingestion time.
- Authenticate through the existing identity provider rather than local accounts.
- Keep an access log covering who queried what, retained separately from the application.
DPP3 — a new purpose needs express and voluntary consent
DPP3 prohibits using personal data for a new purpose that is not, or is unrelated to, the purpose for which it was collected, unless the data subject gives express and voluntary consent. This is the provision that decides whether existing client and staff records can be used to power an assistant at all, and it is answered by reading what people were told at collection.
- Required checks
- Retrieve the personal information collection statements actually used for the data in scope.
- Assess whether the AI use is the original purpose, a directly related purpose, or a new one.
- Where it is a new purpose, plan how express consent is obtained — or narrow the corpus.
- Technical controls
- Tag indexed documents with the collection basis so an out-of-scope source is visible.
Human review required — take this to your counsel
PCPD Model Framework — AI governance and the level of human oversight
The PCPD’s Artificial Intelligence: Model Personal Data Protection Framework recommends that organisations formulate policies, practices and procedures when they procure, implement and use AI solutions, taking into account its recommended measures in AI strategy and governance, risk assessment and human oversight, customisation of AI models and implementation and management of AI systems, and communication and engagement with stakeholders. It is guidance rather than law.
- Required checks
- Decide who owns AI governance internally and what they sign off before a system goes live.
- Run a risk assessment that sets the level of human oversight for this system, and record it.
- Train the people who will use the system, and record that you did.
- Vendor questions
- What documentation do you provide to support a customer’s own AI risk assessment?
- Technical controls
- Give reviewers the retrieved sources alongside the output so oversight is possible in practice.
DPP1 — collection must be lawful, necessary and not excessive
DPP1 allows personal data to be collected only for a lawful purpose directly related to a function or activity of the data user, and requires the data collected to be necessary and adequate but not excessive for that purpose. Indexing a whole document store for an assistant is a collection decision made at scale, and "we indexed everything because it was easier" is the shape of an excessive-collection finding.
- Required checks
- State the purpose the AI system serves, in the terms the business would defend it in.
- List which repositories are indexed and confirm each is necessary for that purpose.
- Check whether the personal information collection statement given to staff and clients covers this use.
- Technical controls
- Scope the index by folder, label or classification rather than by whole drive.
- Exclude repositories that exist for a different purpose, such as HR files, unless they are in scope deliberately.
PCPD checklist — write the internal generative AI policy
The PCPD’s 2025 checklist is explicit about what an internal policy should cover: which generative AI tools are permitted, the permissible purposes, clear instructions on the types and amounts of information that can be inputted into the Gen AI tools, lawful and ethical use and bias, which devices and which categories of employee may use the tools, AI incident reporting, and the consequences of a violation.
- Required checks
- Name the permitted tools, including whether publicly available tools are allowed at all.
- Say which categories of employee may use them, on which devices.
- Give concrete instructions on what may go into a prompt, with examples rather than principles.
- Add AI incidents to the existing incident response plan and say what an AI incident is.
- Technical controls
- Make the sanctioned tool easier to reach than the unsanctioned one; policy alone does not move behaviour.
DPP2 — accuracy, and no longer than necessary
DPP2 requires all practicable steps to keep personal data accurate and not to keep it longer than is necessary for the purpose it is used for. Where a data processor is engaged, the data user must adopt contractual or other means to ensure the processor complies with the same retention requirement. An AI deployment multiplies the copies: embeddings, prompt logs, cached completions and evaluation sets all fall inside this.
- Required checks
- Add every store the deployment creates to the retention schedule with a stated period.
- Confirm the contract with any processor caps their retention and that you can verify it.
- Decide what "accurate" means for a generated answer, and how a wrong one is corrected at source.
- Vendor questions
- How long do you retain prompts, outputs and logs, and can that be reduced contractually?
- Technical controls
- Set a time-to-live on prompt and completion logs.
- Re-index on a schedule so the assistant does not answer from a superseded document.
DPP6 — access and correction, and the log book
DPP6 gives data subjects the right to request access to and correction of their own personal data, with detailed provisions in Part 5 of the Ordinance on manner and timeframe, on when a request may be refused, and on maintaining a log book recording every refusal. A vector index and a prompt log are places that data now lives, and a data access request reaches them.
- Required checks
- Establish how a data access request is answered when the data also sits in an index or a log.
- Establish how a correction propagates from the source document to the index.
- Confirm the refusal log book exists and covers requests touching the AI system.
- Vendor questions
- How do we extract or delete a specific individual’s data from your service, and how long does it take?
- Technical controls
- Keep the source document id on every embedding so a subject can be located across stores.
DPP5 — openness about policies, practices and what you hold
DPP5 requires all practicable steps to make a data user’s personal data policies and practices open, along with the kind of personal data held and the main purposes for holding it. Deploying an assistant over personal data changes the practices, so the published statement has to change with it.
- Required checks
- Update the privacy policy and internal data handling notice to describe the AI processing.
- Say plainly, where people will see it, that an AI system is involved and what it does.
Data stays inside — but the weights still came from outside
Keeping documents on your own server removes the transfer question for the content. It does not remove the supply chain: model weights, container images and dependencies are downloaded from third parties, and a gated repository records who downloaded what and when. That is a procurement and integrity matter rather than a personal data transfer, and it is worth stating explicitly so nobody assumes the system is hermetic.
- Required checks
- Record which model revision you downloaded, from where, and under which licence.
- Note that accepting gated access terms is a contract, and check who accepted it.
- Technical controls
- Verify checksums on downloaded weights and pin the revision rather than tracking a moving tag.
- Mirror the artefacts internally so a rebuild does not depend on the upstream still being there.
Structured issue-spotting to support your own review — not legal advice. Verify against the cited primary sources and your counsel.
What this reading does not know
- Whether any of the data falls into a special or sensitive category.
- Whether any material is covered by legal professional privilege.
06Cost range
| Line | One-off |
|---|---|
| Software | HK$0 |
| Model | HK$0 |
| Infrastructure | HK$31,000 – HK$71,000 |
| Implementation | HK$60,000 – HK$360,000 |
| Total | HK$91,000 – HK$430,000 |
| From year two | HK$75,000 – HK$380,000 a year |
Assumptions
- Software: nil. Every component in this recipe is open source and self-installed, so there is no licence fee. Check each licence for use limits before relying on that (see the recipe's open-source-licensing compliance note).
- Model: nil per month. Open weights are downloaded once and served on your own hardware, so there is no per-token charge; the cost of running them sits in infrastructure.
- Infrastructure: On-premise single 24 GB GPU server, a one-off purchase of 4000–9000 USD (indicative build cost for the complete machine, USD, Aug 2026 — verify with a local supplier). Typically written down over three to five years.
- The purchase price excludes electricity, cooling, UPS, rack space, offsite backup and hardware support cover; those are bracketed in the from-year-two line instead of being left as an unpriced list.
- Implementation: 10–24 FDE-days at 6000–15000 HKD per day. One-off. Covers installation, configuration, ingestion of an initial corpus, an evaluation pass and handover; excludes ongoing support and internal staff time.
- Infrastructure converted from USD using HKMA Linked Exchange Rate System: HK$7.75–7.85 to one US dollar.
- Basis: one-off only — implementation and the hardware purchase. This recommendation has no recurring monthly line at all, so the total is what it costs to stand up, not a monthly bill. What it costs to keep running is the from-year-two line below.
- Sized for 6 users. Every figure is an assessment from the inputs listed above, not a quotation.
- From year two this costs roughly HKD 75,000–HKD 380,000 a year to keep running. That is an order of magnitude for a budget conversation, not a quotation: every line below is derived from the hardware price and the FDE day rate already shown, and no supplier was asked.
- From year two — running the hardware: HKD 3,100–HKD 18,000 a year, taken as 10–25% of the HKD 31,000–HKD 71,000 purchase price and covering electricity, cooling or rack space, offsite backup and hardware support cover together. That percentage band is our own bracket, not a supplier quote — no price was fetched for any of those four items. Replace it with your electricity tariff, rack charge and a support quote.
- From year two — ongoing time: 12–24 FDE-days a year (one to two days a month, the figure the recipe's own cost model uses for support and patching) at HKD 6,000–HKD 15,000 per day = HKD 72,000–HKD 360,000. Model updates, index rebuilds, OS and driver patching, and onboarding questions. Internal staff time costs the same hours whether or not it is invoiced.
- Rounding: every figure above is rounded to two significant figures, because each is an indicative band rather than a quotation. The rounded lines may therefore not add up exactly to the rounded total.
Produced by the same cost model an answer uses, from the declared user count, the hardware profile and the implementation band below. Every figure is a range rounded to two significant figures, and the assumptions above are the model’s own.
07Difficulty
4 / 5
Multiple weeks and a team that has shipped infrastructure
- AssessmentStarting point 2/5: software you install, run and keep running on your own machines.
- Assessment+0.5 You run the model server yourself: GPU drivers, quantisation choice, memory headroom and restarts are all yours to own.
- Assessment+0.5 Connectors into existing systems bring credentials, permission mapping, pagination and incremental sync — usually the part that takes longest.
- Assessment+0.5 Scans or audio have to be converted before a model sees them, and the conversion quality sets the ceiling on everything downstream.
- Assessment+0.5 A multi-step workflow needs branches, retries, an exception queue and someone who owns it when it stalls.
- Assessment+0.5 With only basic technical capability in-house, expect to buy in the setup and the first year of support.
- AssessmentAssessed difficulty 4/5 (2 +0.5 +0.5 +0.5 +0.5 +0.5 = 4.5, rounded and capped to 1–5).
08Implementation path
This reference implements the Invoice capture and extraction recipe, which carries the components, the ordered steps, the commands and the evidence behind each one.
- Implementation
- 10–24 FDE-days
- Use case
- Invoice processing automation
AssessmentAbove the recipe’s 8–20 day band: three languages, the posting integration into an existing accounting system, and an approval queue with an audit trail are all beyond the base pipeline.
This reference would not suit
- A company whose invoices arrive as structured e-invoices already. Then the work is an integration, and a model in the middle adds a failure mode without adding information.
- Under roughly 150 invoices a month. Below that the queue is small enough that the approval workflow costs more attention than the re-typing it replaces.
- A team that wants automatic payment. Every constraint in this design assumes a person approves; removing that assumption changes the risk profile and most of the architecture.
09Evidence
- 01Tier 4official repository / model cardGitHub
GitHub API — paperless-ngx/paperless-ngx
https://api.github.com/repos/paperless-ngx/paperless-ngx
FreshRetrieved 25 Aug 2026sha256:bbcaa5b91a1f1 record
5 of 6 declared references had no stored evidence record at render time and are not listed above.
10Hire or build — next step
If your situation resembles the scenario at the top of this page, the next step is either to build it from the recipe or to describe your own constraints and have them read against the rules rather than against this one.