Sample scope of work: an AI invoice workflow.

Example Parts Distribution Co. (“the Client”) is a mid-sized distributor of industrial parts. Supplier invoices arrive as PDF attachments, some of them scans, in a shared accounts payable mailbox. An accounts payable (AP) clerk opens each one, checks it against the purchase order and keys the header and line items into the Client's accounting system by hand. Invoices wait in the mailbox at busy times, keying errors are found late, and the same invoice is occasionally entered twice.

This project delivers an AI workflow that reads each invoice, extracts its fields, checks them against the Client's own data and writes the result into the accounting system's existing invoice import, with a person reviewing anything the workflow is unsure of and anything above an amount threshold. It runs on the Client's own AI provider account. The goals are:

• AP clerks review and correct extracted invoices on one screen instead of keying them from the PDF.
• Low-confidence items, anything that fails a check and any invoice above the amount threshold go to a person before they reach the accounting system.
• Accuracy is measured before go-live on a labeled test set of the Client's own past invoices, against thresholds agreed in phase 1, and measured again whenever a prompt or model changes.
• Every extraction, check, review decision and correction is recorded, so AP and Finance can see what the AI did and why.
• The Client's IT team can run, change and extend the system after handover without us.

• Mailbox intake. New messages in the shared AP mailbox are picked up automatically, and each PDF attachment becomes one item in a processing queue. Messages without a usable attachment go to the review queue with the reason.
• Extraction. An AI model on the Client's own provider account reads each invoice, including scanned pages, and returns a fixed set of fields: supplier, invoice number, invoice date, due date, purchase order number, currency, subtotal, tax, freight, total, and for each line the description, supplier part number, quantity, unit price and line total. A field that isn't on the invoice is returned empty, never guessed.
• Checks. Each item is checked against the Client's own data: the supplier matches the supplier list, the purchase order exists and is open for that supplier, the lines add up to the total, the total matches the purchase order within the tolerance agreed in phase 1, and the supplier and invoice number haven't been received before.
• Review routing. An item goes to a person when any field is below its confidence threshold, any check fails, the total is above the amount threshold, the supplier is new or unmatched, the invoice mentions new bank or remittance details, or the document isn't an invoice. Thresholds are agreed in phase 1 from the test results (section 7); the amount threshold and tolerances are administrator settings, not code.
• Review screen. A web screen where AP clerks see the invoice next to the extracted fields, with the fields that need attention highlighted, and approve, correct or reject each item with a reason. A second approval by the AP lead for items above the amount threshold.
• Write-back. Approved items, and items that pass every check without review, are written to the accounting system's invoice staging table, where the Client's existing import picks them up as unapproved invoices. Approval for payment stays in the accounting system, as today.
• Test set and scoring. A test set of the Client's own past invoices, redacted and labeled with the AP team, and a scoring run that reports accuracy per field and per supplier group, the review rate and the silent error rate (items that were wrong and would have gone through without review).
• Regression checks. The full test set runs in the CI/CD pipeline whenever the prompt, the extraction schema or the model version changes, and blocks the change if any field falls below its agreed threshold.
• Audit trail. Every item's extracted values, check results, review decisions, corrections, and the prompt and model versions that produced it, recorded with the user and time.
• Sign-in. Single sign-on through the Client's existing identity provider, over OpenID Connect or SAML, with three roles taken from groups the Client's IT team manages: AP reviewer, AP lead and administrator.
• Usage tracking. AI usage recorded per invoice, with an alarm when daily usage passes a limit the Client sets.
• Infrastructure and delivery. Infrastructure defined as code (AWS CDK), deployed through a CI/CD pipeline (GitHub Actions) into separate test and production environments.
• Monitoring. Alarms for processing failures, AI provider errors and timeouts, a growing review queue, write-back failures and sign-in failures.
• Documentation and handover. Runbooks, a data dictionary, architecture and security documentation, and knowledge-transfer sessions, as set out in section 11.

• Approving invoices for payment, paying suppliers or matching goods received. The workflow prepares invoices for the accounting system; approval and payment stay with the Client's existing processes.
• Any change to supplier records, including bank and remittance details. Invoices that mention new details are flagged for a person and never update anything.
• Credit notes, statements, quotes and other document types. They are recognized and sent to the review queue unprocessed; extracting them is a candidate for a later phase, quoted separately.
• Any mailbox other than the shared AP mailbox, and invoices that arrive on paper or through a supplier portal.
• Training or fine-tuning AI models. The workflow uses the chosen provider's models as they are, with prompts, a fixed output schema and the Client's own data for checks.
• Any write to the accounting system other than the invoice staging table.
• Mobile apps and offline use.
• Integration with any other business system.
• Hardware, network changes, software licenses and AI provider subscriptions. We specify what is needed; the Client's teams make the changes and hold the licenses and accounts.
• Support, maintenance or new features after handover. Available as separately quoted work.

• The Client provides the access in section 4 before the build phase starts. If access arrives later, the schedule moves with it; the price changes only if the scope does.
• The Client has, or opens, a business account with one of Anthropic Claude, OpenAI, Google Gemini or xAI Grok. Which provider and model to use is decided in phase 1 by running the tuning part of the test set against the candidates the Client is willing to use. AI usage is billed to that account.
• The Client's IT security team confirms in phase 1 which data may be sent to the chosen provider, and which retention and training settings apply under the Client's own agreement with it.
• The AP team provides the past invoices for the test set, and AP clerks label the expected answers with us using a written labeling guide. Two clerks label a shared subset independently so ambiguous rules are found and settled.
• Finance and the AP lead sign off, in phase 1, the per-field accuracy thresholds, the acceptable review rate and silent error rate, the amount threshold and the purchase order tolerance, based on the baseline and the first test results.
• The accounting system's existing import from the staging table works and is documented. Changes to that import are the Client's.
• The supplier list and purchase orders in the accounting database are correct. Where they aren't, the Client corrects them in the accounting system; the workflow doesn't keep its own copy.
• A site-to-site VPN (or AWS Direct Connect) links the Client's network to its AWS account, set up by the Client's network team.
• The Client names one product owner who can answer questions and accept deliverables, and one contact each in AP and IT security.
• The test environment uses the redacted test set and a copy of the accounting views with test data. No unredacted production invoices are used in test.
• Hosting, license and other third-party costs are billed to the Client's own accounts.

• Source code for the workflow and the review screen, with automated tests, in the Client's repositories.
• The prompts and the output schema, versioned in the Client's repositories alongside the code.
• The redacted test set, the answer key, the labeling guide and the scoring script, in the Client's repositories under the same access controls as the source data.
• Database migration scripts for the workflow's own tables, run by the pipeline, so the schema is versioned with the code.
• Infrastructure as code (AWS CDK) for the test and production environments.
• A CI/CD pipeline (GitHub Actions) that tests, builds and deploys every change, runs the test set when a prompt, the schema or the model version changes, and authenticates to AWS with OIDC so no AWS keys are stored.
• An architecture and data-flow document for the Client's security review, including every network rule with its source, destination, port and purpose, and exactly what is sent to the AI provider.
• A data dictionary covering every extracted field with its format and normalization rule, and every table, view and field the workflow reads or writes.
• Test reports: the phase 1 baseline, each scored run during the build, and the final run on the held-out part of the test set.
• Runbooks: deploy, roll back, rotate credentials (including the AI provider key), change a threshold or the amount limit, run the test set and read its report, add corrected items to the test set, upgrade the model version, and respond to each alert.
• Knowledge-transfer sessions, listed in section 11.

The system is accepted when every criterion below passes in production. Each one is checked together with the Client's product owner.

Accuracy criteria are measured on the held-out part of the test set: invoices from the Client's own history, labeled with the AP team, that are never used while prompts are being tuned. Each field is scored separately after normalization, so a better average can't hide a worse total or date.

Accuracy, review-rate and silent-error thresholds, the amount threshold and the purchase order tolerance: stated here in the real document, agreed with the Client in phase 1 from the baseline and the first test results.

Acceptance is judged against these criteria only. Anything not listed here is not a reason to withhold acceptance, and is not in the price; it can be raised as a change (section 9).

Work runs in five phases. Each phase ends on a written exit criterion, and scored test runs and working software are reviewed with the Client in the test environment throughout phases 2 and 3.

Milestone dates: stated here in the real document, agreed with the Client before work starts.

1. Either party raises a change in writing: what is needed and why.
2. We reply in writing with its effect on scope, price and schedule, or confirm that it has none.
3. Nothing changes until the Client's product owner approves it in writing. Approved changes are added to this document as numbered amendments.
4. A change that isn't approved isn't built, and the original scope and price stand.

Until the system is accepted, fixing something that fails an acceptance criterion in section 7 is not a change. It is covered by the fixed price.

The following are prepared for the Client's IT and security teams during phase 1, before the workflow connects to any Client system or sends any invoice to the AI provider:

• A data-flow diagram showing every connection and its direction, including exactly what is sent to the AI provider: the invoice pages and the instructions for the fixed set of fields, and nothing from the accounting database.
• A network rule list: source, destination, port, protocol and purpose for each rule. The only connection into the Client's network is the workflow's SQL Server connection over the site-to-site VPN, on a single network rule the Client's network team controls.
• The AI provider's retention and training settings for the Client's account, reviewed with IT security under the Client's own agreement with the provider.
• Database logins: one read-only login for the accounting views and one that can only insert into the staging table, named and documented. No shared or personal credentials in the running system.
• The model only returns fields in a fixed schema. It has no access to the Client's systems and cannot send email, write data or call other services; every write is made by the workflow's own code after the checks.
• Text in an invoice, such as instructions to ignore rules or pay a different account, is treated as content to extract, never as an instruction. Invoices mentioning new bank or remittance details always go to a person.
• Sign-in only through the Client's existing identity provider, so the Client's existing multi-factor and access policies apply. Roles come from groups the Client's IT team manages in that identity provider.
• Secrets, including the AI provider API key, kept in AWS Secrets Manager, never in code, configuration files, tickets or email.
• Encryption in transit on every connection, and at rest for stored invoices, the test set, extracted data and backups.
• Logging of sign-ins, deployments, provider errors and application errors to CloudWatch, retained according to the Client's policy.
• Dependency scanning in the pipeline, with findings reported to the Client before each release.
• Data classification: supplier names and addresses, invoice details, purchase order references, and the names and work email addresses of AP staff. The test set is redacted with consistent placeholders and kept under the same access controls as the source invoices.
• Answers to the Client's security questionnaire, and an architecture walkthrough for the security team.

Handover is part of the fixed price. It is complete when the Client's team has deployed a change, rolled it back and responded to a test alert themselves, using only the documentation. It includes:

• Everything in section 6, confirmed in the Client's repositories and accounts.
• Knowledge-transfer sessions: architecture walkthrough, code tour, supervised deployment, rollback and recovery, running the test set and reading its report, changing a threshold, and a test incident.
• Access and credentials: every account confirmed as the Client's, secrets rotated, and our access removed or reduced to whatever support is agreed.

The full contents of a handover package are shown in the sample handover package. It was written for a different invented project, a plant-floor dashboard, but it is organized the same way for a workflow like this one.

• The Client owns all code, infrastructure definitions, documentation and data produced under this scope. There is no license fee and no lock-in.
• Everything is built in the Client's repositories and AWS account. Nothing runs in accounts we control.
• Open-source components remain under their own licenses, which are listed in each repository.
• Confidentiality is covered by the NDA signed before this engagement.

Fixed price: stated here in the real document.

The fixed price covers everything in sections 2, 6, 7 and 11: design, build, testing, deployment to test and production, documentation, knowledge transfer, handover, and fixing anything that fails an acceptance criterion before acceptance.

It does not cover:

• Anything listed as out of scope in section 3.
• Approved changes under section 9, each priced before it starts.
• Hosting, software licenses and other third-party costs, billed directly to the Client's accounts.
• Support, maintenance or new features after handover, quoted separately if wanted.

Invoicing schedule and payment terms: stated here in the real document.

Nothing is built until this scope is accepted. Signing below accepts the scope and the fixed price stated in section 13.