Invoice work is a good Analyst task because the hard part is not opening PDFs. The hard part is applying one rule consistently and showing where the evidence does not fit.
Put the rule before the files
Define what counts as a match before asking the assistant to review anything. Include the fields that must agree, the tolerance for rounding, how credit notes should be handled and which missing values should become exceptions.
Then place the source files in the active project or identify the folder Analyst may read. Ask for results under output, where Analyst is allowed to write.
Ask for evidence, not confidence
A useful exceptions table includes the source filename, invoice number, compared values, the rule that failed and a short explanation. It should not hide uncertainty behind a confidence score.
Start with a small sample. Review the result, correct the rule and only then run the larger folder. If the PDFs are scanned images, Artifact can use bundled on-device OCR to turn them into text before the document is edited or cited.
Keep the final decision human
The assistant can locate duplicates, missing purchase orders and inconsistent totals. It should not silently approve a payment or change an accounting record. Those are separate actions with separate authority.
Once the review format is stable, the same job can become scheduled work. Temporal keeps the recurrence, and the connected desktop reads the local folder when the run is due.
Build a source folder the assistant can understand
Start with a copy of representative files, not the only copy of the month-end archive. Use predictable filenames when possible, and keep the ledger export beside the documents or in a clearly named subfolder. If several legal entities or currencies are mixed together, separate them or state how the rule changes for each group.
Analyst can read across the active project, but organization still matters. A clean source folder reduces false matches and makes every exception easier for a person to trace. It also gives you a stable test set for refining the instruction before a larger run.
Ask the assistant to inventory the source before comparing anything. The inventory should state how many files it found, which formats are present, whether any files could not be read and which date range appears to be covered. These are observations about the run, not performance claims about the product.
Turn business judgment into explicit tests
People often carry matching rules in their heads: the supplier name may vary, tax can be rounded, one purchase order may cover several partial deliveries, and a credit note should reduce rather than duplicate a total. The assistant cannot infer every local convention safely.
Write each rule as a test with an outcome. For example:
- Match purchase-order identifiers after removing harmless spacing and case differences.
- Compare supplier identity using the approved alias table, not general similarity.
- Treat a configured amount difference as rounding only when currency and tax treatment agree.
- Flag missing identifiers instead of guessing from nearby text.
- Keep duplicates separate until a person confirms whether one is a revision.
The alias table and tolerance should live in the project so future runs use the same policy. If a rule changes, record the date. A result is only reproducible when the decision rules are versioned with the work.
Handle scanned and imperfect documents
Some PDFs contain selectable text; others are page images. Artifact can use bundled on-device OCR for scanned PDFs, but OCR output is still an interpretation of pixels. Ask the assistant to preserve the source filename and page reference for extracted values, especially totals, dates and tax identifiers.
Do not let a clean table hide an unreadable page. The exceptions report should distinguish “value disagrees” from “value could not be read.” Those conditions require different follow-up.
The same principle applies to spreadsheets. Merged cells, repeated headers and totals inside the data range can produce plausible but incorrect rows. Have the assistant describe the detected columns and show a small normalized sample before processing the full ledger.
Separate three kinds of output
A useful review produces three layers:
- A run summary: sources read, dates covered and files skipped.
- A machine-readable comparison table containing every reviewed item.
- A short exceptions brief containing only cases that require attention.
Write all three under output. The comparison table lets another tool or later run continue the work. The exceptions brief is what a person can review quickly. The run summary tells you whether the result is complete enough to trust.
Avoid asking for only a narrative. Prose is valuable for explaining patterns, but it is a poor substitute for a row-level audit trail.
Review the first sample together
Choose five to ten documents that include ordinary matches and known edge cases. Ask Analyst to apply the rule and explain each exception. Correct the rule, not just the individual answer. Then rerun the same sample and confirm that the change fixed the intended case without loosening another condition.
Only after that should you widen the folder. Even then, inspect a random set of matches as well as every exception. A system can miss problems by classifying them as normal, so reviewing only the red rows is not enough when the decision has financial consequences.
From review to recurring preparation
Once the instruction, folder structure and output format are stable, schedule the preparation stage. The connected desktop can read the new local files, apply the documented rule and write the next exceptions package. Keep payments, record changes and external messages outside that scheduled authority unless your process has a separate, deliberate approval design.
The goal is not to claim that month-end disappeared. It is to make the repetitive comparison visible, repeatable and easier to verify, leaving people with the cases that actually require judgment.
Ask Upfyn
Help me define an invoice-matching rule for this project. Inspect only a small sample first, write an exceptions table under output, cite each source filename and stop before taking any external action.