The Last Invoice Is Not the Handover: 12 Acceptance Tests for a Swiss SME AI Project

The Last Invoice Is Not the Handover: 12 Acceptance Tests for a Swiss SME AI Project

A Swiss SME should accept an AI consulting deliverable only after it can prove three different things: the contracted result exists, a named employee can operate it without the consultant, and the business can stop or replace it without losing essential records. A demo, a repository invitation, or a folder of PDFs proves none of those on its own. This article turns the broad provider-selection questions in IAPME Suisse’s comparison of Swiss AI partners into a buyer-side acceptance mechanism that can be attached to a statement of work (SOW). The point is not to demand that every SME own every model or cloud account. It is to make the intended boundary, the proof, and the consequence of a missing item explicit before the final invoice.

The short recommendation is to define a small evidence schedule at kickoff, rehearse it with the receiving team near the end, and sign only against observed pass conditions. For a simple hosted service, “handover” may mean a usable export, access to the customer’s workspace, a named operator, and a tested cancellation path. For a custom workflow, it may also include source code, deployment instructions, a safe rollback, evaluation fixtures, data-flow notes, and rights to use the delivered components. The contract should distinguish those cases instead of treating “all materials delivered” as a universal test.

What this article adds, and what it does not claim

The existing Swiss agency-comparison page discusses sector fit, data handling, measurable objectives, training, maintenance, exit conditions, and portability. Current handover checklists already commonly mention repositories, accounts, runbooks, evaluation material, owner training, and a period of transition support. For example, FISTA’s AI handoff checklist asks whether a receiving owner can operate the system through a normal cycle and a simulated failure; a buyer worksheet by Marius Manolachi similarly asks whether the client can run, change, evaluate, recover, and retire the workflow. Repeating a generic “ask for the code and documentation” list would therefore add little.

The missing operational bridge is a contract-ready row that joins five elements: the promise, the artifact, the person who receives it, the test that proves it is usable, and the route if it fails. A file can be present but unusable; access can exist but be scoped to the wrong tenant; a test can pass on the consultant’s laptop but fail in the client’s clean environment. The proposed 12-row schedule makes those distinctions visible. Its value is not a claim that this exact schedule is legally required or empirically optimal. It is a reusable way to stop “delivered” from being confused with “accepted.”

Research method, date, and boundaries

Research snapshot: 31 October 2026. I reviewed the selected IAPME comparison page, seven currently visible English-language pages or guides on AI/software handover and buyer acceptance, four primary or recognized sources (Innosuisse, the European Data Protection Board, ISO, and EY), and one official enforcement report used only to examine the risk of unsupported business claims. I also reviewed a publicly indexed practitioner question asking what an AI agency should hand over; it illustrates the question people ask, not how common the problem is. The search result sample is purposive, not a census: it was selected for direct relevance to “AI consultant handover,” “who owns the system,” and “handover checklist.” Pages can change, search results vary by location, and this review does not measure market prevalence. I also screened an indexed AI-agency delivery tutorial: its delivery sequence places a handoff call after client testing and describes the call as demonstrating results and presenting an upsell. That is a useful seller-side delivery view, but the page does not set a buyer acceptance test; its revenue and retention claims are not used as evidence here. See the tutorial’s delivery section.

The asset below is a designed acceptance schedule and a synthetic worked example. It is not a field study. The example uses one invented Swiss SME workflow and 12 artifact categories; it excludes real client records, actual vendor contracts, production performance data, legal opinions, and any claim about failure rates or savings. Numeric weights are explicit decision aids chosen for the example, not measured benchmarks. Replace them with the project’s risk appetite and have counsel review contractual language, especially where regulated data, employment decisions, IP, or cross-border processing is involved.

First separate delivery, acceptance, and operational ownership

Delivery is the act of handing over a file, credential, or service. Acceptance is the buyer’s recorded judgment that a defined requirement has been met, or that a documented exception has been agreed. Operational ownership is the continuing ability to keep the result safe, useful, and supportable after the engagement. These are related but not interchangeable. A supplier can deliver a source archive that the customer cannot build. A buyer can accept a milestone while intentionally purchasing a managed service that the buyer will never operate. A project can satisfy the SOW and still be a poor business investment if the agreed metric was weak.

Write the contract schedule so each row names the intended state. “Repository access provided” is a delivery statement. “A customer-controlled maintainer checks out the tagged release, installs it using the written instructions, runs the smoke suite, and records the resulting version” is an acceptance test. “The SME has chosen a managed service and receives a documented export and termination route instead of source ownership” is a legitimate alternative state. The test should verify what was purchased, not force a preferred architecture.

This distinction also prevents a late-stage argument about what “complete” meant. At kickoff, the parties can agree which requirements are acceptance criteria, which are informational handover items, which are optional, and which are excluded. If a requirement is excluded, record who will own the resulting risk or follow-on work. An explicit, bounded exception is easier to manage than a vague promise that the consultant will “help as needed.”

Evidence: facts, rules, inference, and recommendation

The official sources provide boundaries, not a ready-made SME consulting contract. Innosuisse says partners in its innovation-project programme must specify intellectual-property and usage rights no later than three months after project start, and recommends addressing them early. That timing applies to the programme described on Innosuisse’s implementation-partner page; it is not a deadline imposed on every Swiss consulting engagement. The practical inference is narrower: ownership and usage terms are costly to leave until a final handover meeting, so the buyer and provider should establish them during scoping.

Where the GDPR applies, the EDPB explains that controller and processor roles are functional and depend on the parties’ actual purposes and means, rather than the label placed in a contract. See the EDPB’s final Guidelines 07/2020. Do not infer from that EU guidance alone how a Swiss-only service is classified under Swiss law. Map the actual data flow, identify the applicable regimes with qualified advisers, and describe responsibilities in terms that match reality.

ISO/IEC 42001 specifies requirements for an AI management system that organizations establish and continually improve. It is a management-system standard, not a checklist for accepting one consultant’s code drop. The useful connection is operational: an SME that has governance roles, monitoring, risk review, or improvement processes should receive enough evidence to keep those processes alive when the project team changes. The standard is not a certification requirement for every small business.

EY’s vendor questions for responsible AI cover risk assessment, data management, technical documentation, monitoring, incident response, training, audit rights, and contractual accountability. That is a useful consulting checklist, but its audience is corporate third-party risk evaluation. This article translates selected concerns into acceptance evidence a small receiving team can actually test. As a counterweight to optimistic project claims, the US FTC’s 2025 Air AI case announcement describes allegations about deceptive growth, earnings, and refund claims. It is a US lawsuit, not a Swiss legal rule or a finding that every AI vendor exaggerates. Its lesson here is simply to record the baseline, calculation, and conditions behind any promised business outcome.

The five-part acceptance row

For every material deliverable, fill in five columns before build begins. First, state the promise in testable terms: “the invoice assistant extracts supplier name and invoice date from the approved document set” is clearer than “use AI to streamline accounts payable.” Second, name the artifact that makes the promise inspectable: versioned workflow, configuration, evaluation cases, access map, monitoring export, or signed rights schedule. Third, name the receiving person by role, not merely “the client.” A business owner can judge whether the workflow handles an exception; an engineer can verify a deployment; a privacy lead can review a data path.

Fourth, describe a test and an unambiguous pass observation. Avoid “satisfactory to the customer” without examples, thresholds, or an agreed method to resolve borderline outputs. Fifth, specify the next step if it fails: fix, retest, accept with a named exception, replace the deliverable, or terminate the milestone under negotiated terms. The contract should say who pays for retest effort and how long either party has to raise a documented defect. Those details are commercial choices; the schedule is a prompt for discussion, not a substitute for legal drafting.

A strong row has a stable identifier that also appears in the issue tracker and evidence folder. The identifier makes it possible to trace a requirement from proposal to demonstration to acceptance. It also prevents a common handoff problem: people remember that “privacy” was discussed, yet cannot find the specific data-processing decision, owner, or proof. The row’s artifact must be retained where the SME can lawfully access it after the consultant’s account closes.

When to use a lighter or heavier gate

A single-user prototype built on synthetic or public data may not justify an enterprise-grade package. Its minimum evidence could be a short scope statement, sample inputs and outputs, a list of limitations, a kill switch, and a clear decision on whether any project data may remain. A customer-facing workflow that reads personal information or triggers consequential actions deserves stronger identity, access, logging, review, incident, and recovery evidence. The criterion is exposure and recoverability, not the word “AI.”

A managed SaaS purchase also changes the ownership question. The buyer may not own model weights or source code and may be unable to inspect all internal controls. In that case acceptance can focus on account ownership, configuration export, data export/deletion process, support commitments, subprocessors or service dependencies where disclosed, and the operational steps needed to change supplier. If the vendor cannot expose an item, record it as a dependency and decide whether the remaining risk is acceptable. Never present a missing vendor document as proof that the system is safe.

For a Swiss SME working under an innovation grant, a separate IP calendar may exist. Innosuisse’s three-month timing is relevant to its funded partner projects; it does not mean every ordinary SOW has that same deadline. A buyer should identify the applicable agreement and ask counsel which IP schedule it controls. By contrast, the acceptance schedule described here is a practical project-management recommendation. It creates a shared record, but it does not itself transfer copyright, guarantee compliance, or replace any mandatory agreement.

The 12-artifact acceptance schedule

Use the table as a starting schedule, then delete rows that do not fit and add project-specific ones. “Pass evidence” is what the receiving person observes, not simply the name of a file. A critical row should be marked hard-gate or weighted, and the commercial consequence should be written into the SOW by the parties.

The schedule deliberately distinguishes artifact possession from capability. A source archive without build steps fails A5 even if the archive is complete. A dashboard screenshot without a threshold and recipient fails A9. An evaluation file that the business owner cannot explain may satisfy delivery but not A6’s operational aim. Conversely, a managed service may pass A5 through a configuration export and documented provider dependency rather than customer-owned source code. The row must describe the purchased relationship, not hide its limits.

Not every row is equally critical. A1, A3, A4, A7, A8, A10, and A12 often deserve hard-gate status when the workflow touches customer records, systems, or consequential actions. A2 and A6 should be hard gates if the project is being sold on a measurable business result. Other low-risk prototypes may use weighted scoring and explicit exceptions. The word “often” matters: a one-off internal demonstration on dummy data may have different consequences from a production service connected to a live ERP. Let the risk analysis, data, actions, and recovery route determine the gate.

A decision rule that does not pretend to be a benchmark

A simple decision rule helps a team avoid averaging away a fatal gap. First apply hard gates: if a critical privacy boundary is unknown, credentials cannot be rotated, no safe stop exists, or the receiving party cannot access the contracted deliverable, do not convert that into a passing average. Record the failure and pause acceptance of the affected scope. Then, for non-critical rows, assign a risk weight and evidence score.

For a synthetic exercise, set each weighted row’s evidence score to 0 when absent, 1 when present but not independently checked, and 2 when the named recipient executed the test and recorded the result. Compute weighted completeness as the sum of weight multiplied by evidence score, divided by twice the sum of weights. This gives a value between zero and one, but it is a completeness indicator for this chosen evidence schedule, not an AI quality score or prediction of success.

For example, if three weighted rows have weights 3, 2, and 1, and recorded scores 2, 1, and 0, the numerator is 8 and the maximum is 12; the illustrative completeness is 0.67. The score helps the team locate weak evidence. It should not override a failed hard gate, a disputed legal right, or a business decision to reject the project. Use “not applicable” only with a reason and the approver recorded. Do not silently drop a difficult row from the denominator after the test fails.

The receiver should also distinguish a test result from a decision. “A3 passed” means the named recipient traced the specified record through the documented path on a given date. It does not mean no other path exists, all legal duties are fulfilled, or no future change will alter data handling. Add a scope/version note to every receipt. A test can establish a bounded fact about a bounded version; it cannot certify the entire vendor or system for all future configurations.

Worked example: invoice intake without automated payment

Consider a synthetic Vaud-based distributor that wants an assistant to read supplier invoices, extract supplier name, invoice date, reference, and total, then prepare a draft entry for an employee to review. It must never approve or release a payment. The consultant’s proposal says it will “reduce manual invoice effort,” but it does not yet define a baseline, tolerable extraction error, exception flow, or who maintains the service. The company is not yet ready to sign acceptance based on a polished presentation.

At kickoff, the parties revise the promise into a bounded scope: for a named sample of invoice layouts and a chosen time window, the tool prepares a draft with source-page references; a staff member confirms every field before the draft can enter the accounting system; missing, conflicting, low-confidence, or unsupported values route to a manual queue. They explicitly exclude payment authorization, supplier bank-detail changes, legal invoice validation, and any inference about whether an invoice should be paid. The company decides whether the system may use live documents, which supplier service handles them, and what must be removed at close.

At acceptance, the finance owner selects a held-out set of permitted examples, including rotated scans, duplicate invoice numbers, a changed supplier layout, a missing reference, and a malformed total. The consultant does not choose only the best demo cases. A business operator checks that each extracted field has a source reference, rejects one draft, and confirms that no downstream payment action occurs. A technical owner repeats the run using the tagged release and customer-owned environment or documented managed-service account. The purpose is to prove the contract’s specified controls, not to claim a universal accuracy percentage.

The parties record the test version, who selected the examples, what was excluded, and the observed result. If a value is uncertain, they do not quietly count it as correct because the screen looked plausible. They define how to resolve a disagreement: inspect source evidence, label the case ambiguous if the input itself is unreadable, and rerun only after both sides agree on the rule. Any threshold—for example, a minimum field-level extraction score—must be chosen before the final test and tied to the business risk. This fictional example does not provide such a threshold because no empirical data or invoice corpus was measured for this article.

The acceptance receipt may say: “A6 passed for release R3 on the agreed sample; 2 cases were excluded as unreadable scans under the signed rule; 1 layout change is a known limitation; manual approval remains mandatory; production monitoring owner is the finance lead; next evaluation date is assigned.” That is much more informative than “AI delivered successfully.” It also preserves a clear separation between the observed acceptance result and the larger question of whether the tool is worth operating.

Use a weighted score only after hard stops

A weighted score is useful when a team must prioritize remediation across many ordinary gaps. It is dangerous when it allows a serious unknown to disappear inside a high average. The first step is to label each row as either a hard gate, a weighted requirement, or informational handover. A hard gate is a condition whose failure prevents the affected production scope from being accepted. A weighted requirement has a documented score and agreed threshold. An informational item records context but does not itself decide acceptance.

One reproducible method is:

1. Define a risk weight from 1 (minor inconvenience) to 3 (material operational, financial, privacy, or safety exposure).
2. Score evidence 0 (missing), 1 (supplied but not checked by the recipient), or 2 (recipient executed and recorded the test).
3. Calculate completeness as the sum of weight times score divided by the sum of weight times 2 over applicable weighted rows.
4. Keep hard gates outside the formula. One failed hard gate remains a failure regardless of the percentage.
5. Record exclusions before testing, with owner and reason.

A buyer may choose a minimum, such as 0.85, for weighted completeness, but that number is only an example chosen for a contract discussion. It is neither a legal standard nor a research-derived cutoff. The buyer should prefer a short list of well-chosen hard gates over an impressive-looking score with arbitrary weights. For a low-risk experiment, a lower score with explicit residual risk may be acceptable. For a workflow touching payments, health records, staff decisions, or customer-facing commitments, the owner may decide that even one unresolved item is too risky.

When the parties disagree about a score, go back to the evidence, not the arithmetic. Was the test actually run by the receiving person? Is the test version the delivered version? Did the environment use the configuration that will remain in production? Is the failure within an agreed exclusion, or was the exclusion added only after the result? A spreadsheet can make these questions visible, but it cannot adjudicate them. Name an escalation person and a time limit in the SOW.

A sample schedule as editable YAML

The following block is a starting data structure for a handover register. It can live in a spreadsheet, issue tracker, or repository. It is not a legal clause and should not contain secrets, personal data, raw customer records, or unrestricted access tokens. Keep the test evidence in a controlled location and link to it using stable IDs.

project: SME-invoice-assistant release: R3 acceptance_date: 2026-10-31 scope: allowed: "Prepare draft invoice fields with source references" prohibited: ["approve payment", "change supplier bank details"] rows: - id: A5 owner_role: technical_owner artifact: "tagged source, lockfile, deployment notes" test: "recipient builds tagged release in clean environment" pass_observation: "smoke suite passes; release hash recorded" critical: true status: pending - id: A6 owner_role: finance_owner artifact: "permitted evaluation set and rubric" test: "recipient inspects exceptions and source references" pass_observation: "each case has a recorded decision" critical: true status: pending - id: A10 owner_role: operations_owner artifact: "rollback target and manual fallback runbook" test: "disable assistant and complete one manual intake" pass_observation: "no payment action; manual route works" critical: true status: pending exceptions: - row_id: A3 reason: "supplier API region not confirmed" approver_role: privacy_lead expires_on: null 

Each status transition should have a timestamp, actor, release identifier, and evidence reference. If the project does not have the named owner role, assign a person and backup before acceptance. The example deliberately leaves a known data-region question unresolved; that should block live-data use if the risk owner says location is a condition of launch. It must not be “closed” merely because the vendor verbally said it was fine. The right action may be to use synthetic data, obtain written provider evidence, select a different configuration, or defer the live pilot.

From kickoff to acceptance: a practical sequence

At kickoff, the buyer and provider should agree on the boundary and the rows that matter. A useful kickoff pack names the business outcome, the current measurement process, data categories, integrations, users, human decisions, prohibited actions, delivery model, rights assumptions, and the person who can accept each item. This is not an attempt to predict every technical choice. It is a way to stop a broad promise from silently becoming a narrower demonstration. If the supplier will use a hosted model, a subcontractor, or an external knowledge source, record what is known and who will update it when the configuration changes.

The parties should also decide which tests use synthetic data, which require approved real data, and who may authorize that use. For each test, capture an identifier, version, owner, expected observation, exclusions, and handling rules for evidence. A sample data file can itself contain confidential information, so the evidence pack should point to a controlled repository rather than copying material into an email or contract attachment. The test design must reflect the business process, not expose more data simply to make the demo look realistic.

At the first working release, the supplier should demonstrate the system against the acceptance schedule before the final acceptance event. This is a rehearsal, not a second opportunity to redefine success after observing the results. The receiving people should be present and should perform the relevant tasks themselves: find the correct artifact, run the test, identify a known limitation, and record a defect. If the receiving team cannot use the schedule because the language is unclear or the environment is unavailable, that is useful evidence of an incomplete transfer even if the core software works.

Before the acceptance date, freeze the version and scope of the test. Record the release identifier, configuration, evaluation data version, external services, known exceptions, and the party that prepared each item. The buyer should select or approve the test cases under the agreed method. If a provider update changes the model, prompt, retrieval source, data transformation, or integration, decide whether it is a new release requiring a partial rerun. Do not compare a new output to old evaluation results without disclosing the change.

At the acceptance event, run a clean sequence, not a slide presentation. The business owner supplies a representative permitted case, sees the result and its supporting evidence, and routes an exception. The technical owner verifies the deployed version and safe-stop path. The contract owner checks that rights, access, invoices, and remaining tasks are consistent with the schedule. A single meeting can do this for a small project; a larger one may need distinct sessions. The decision record should include pass, fail, pass with exception, or not tested—never a blank cell interpreted as “yes.”

After acceptance, transition residual work to named owners. Document any supplier support period, response path, service fees, renewal dates, open defects, next test date, and trigger for revisiting the scope. If there is no internal technical capacity, a managed service can be the sensible operating model. The buyer still needs to know what stops if the service ends and how to restore the manual process. Acceptance is a boundary between project delivery and the next operating arrangement, not proof that maintenance has become unnecessary.

Let the receiving team run a cold test

A cold test asks a person who did not build the system to execute the important procedure using only the accepted materials and the access they are supposed to retain. The consultant may observe and answer questions only within the agreed support rules; if they silently perform the steps, the test proves the consultant can do it. A cold test can be short: check out a tagged release, inspect a sample result, record an exception, disable the integration, or follow the manual procedure. The task should be chosen because it exposes a project-specific risk.

The observer records every dependency the recipient had to ask about: which account to use, which configuration was current, whether a secret was missing, where the test data lived, why an output was rejected, and how to restore the prior state. Those questions become defects, documentation updates, or explicit dependencies. If the SME elects to accept a service it cannot run internally, the cold test should verify the alternative that was purchased: customer account access, export ability, support route, service status visibility, and the documented termination process.

A cold test is not the same as a security penetration test or certification audit. It is a narrow usability and continuity check on a named release, and it can still miss latent defects or hidden dependencies. Record the sample and exclusions. For any high-consequence use, involve an independent technical or compliance reviewer whose mandate is clear. Do not let a “handover test” claim more assurance than it actually provides.

Turn the schedule into usable SOW language

A schedule is useful only if the contract says how it affects delivery and payment. Ask counsel to review wording that defines acceptance, defect categories, notice periods, rework obligations, deemed acceptance, partial acceptance, support, termination, liability, data return, and IP. Those terms interact with the governing law and the rest of the agreement. The table in this article is a scoping tool, not a clause that can safely be copied unchanged into a Swiss contract.

A practical SOW structure uses four layers. The main body describes the project purpose, parties, fees, change control, confidentiality, and general legal terms. A scope annex lists deliverables and exclusions. An acceptance schedule describes tests and evidence by row ID. A dependency and rights register records pre-existing materials, third-party services, accounts, data handling, licence terms, and the owner of each ongoing cost. Keep these documents versioned and cross-reference IDs instead of copying entire paragraphs into several places. If an agreed term changes, update the controlling document and note the date.

Before signing, inspect verbs. “Provide access” is weaker than “transfer owner role to the customer’s organization account and verify the named administrator can invite and revoke a test user.” “Document the model” is weaker than “record the model endpoint or version, settings that affect the delivered behavior, retrieval source version, and process used to identify a provider change.” “Deliver a dataset” may be inappropriate if the customer has no continuing right to retain it. The text should describe permitted rights and actions, not just objects.

Include a condition for “not applicable.” The provider should explain why an item does not apply, the buyer’s named owner should approve the explanation, and the schedule should record the dependency or residual risk. A service that intentionally remains vendor-operated may not need customer source code; it still needs some way to leave or keep access to business records. A custom project may rely on provider-managed base models that cannot be transferred. The acceptance record can acknowledge that dependency, state the alternative, and avoid language that implies ownership of what the customer is only licensed to use.

Treat data, intellectual property, and access as separate questions

Teams often put “ownership” into one row, but it contains distinct questions. Who owns or can use the custom deliverables? What rights apply to background tools and libraries? Can project data be retained, used for evaluation, or used to train a service? Who administers the provider account? Who holds a licence or subscription? What happens to logs and backups on exit? The answer may differ for each item. In a grant-funded innovation project, Innosuisse’s specific IP and usage-rights milestone is a reminder to surface the agreement early; the programme rule does not settle terms for unrelated consultancy work.

If personal data is involved and the GDPR applies, the actual division of processing activities matters. An annex should identify who decides why data is processed, which service providers process it, what instructions apply, what evidence of access exists, and what happens to the data at closure. The EDPB’s role guidance is about the GDPR concepts; it does not determine Swiss FADP obligations, cross-border transfer rules, employment law, or sector-specific duties. A local privacy professional should review the actual facts. For a test, prefer synthetic or minimized data until the responsible owner approves a production data path.

Never put live API keys, passwords, or personal records into the handover document. Transfer access through each provider’s official account mechanism, record the owner and role, then rotate credentials where the parties agreed. A security test should confirm that the customer can remove departing supplier access without locking out the service, and that a support account has a named purpose and expiry or review date. The provider may need continued access for support; that should be least-scoped, logged where practical, and governed by a separate support arrangement rather than an informal shared password.

Measure promises without converting an estimate into proof

If the consultant promises “hours saved,” the SOW should name the workflow step, measurement window, denominator, data source, exclusions, review effort, and the person responsible for recording the result. If the old process has no trustworthy baseline, the parties can create one before implementation or agree that business impact is a hypothesis to test later, rather than an acceptance condition. In either case, capture the distinction. A demo can show a feature; it cannot establish sustained savings across changing monthly volume.

The calculation should account for work the automation creates as well as work it removes. For example: net time change equals baseline processing time minus assisted processing time, minus review and exception handling, minus recurring operational work. The inputs should use comparable cases and define which are excluded. If processing time falls but error correction increases, the raw speed metric is not a complete business result. If the system only handles a subset, report the subset and its selection rule rather than extrapolating it to all work.

Do not use a single average to hide a dangerous tail. Report the number and type of cases in the evaluation fixture, distinguish routine from edge cases, and state which cases were unavailable. For high-impact outputs, a small set of carefully selected safety checks may matter more than an aggregate score. A buyer and supplier can agree on a threshold, but the article’s example formula and any sample threshold are not external benchmarks. The threshold should be justified by business impact and reviewed when the workflow or model changes.

The FTC’s Air AI announcement concerns an alleged US scheme involving unrealistic business-growth, earnings, and refund promises. It is not evidence that a particular Swiss SME project has been misrepresented. It does illustrate why contract language should make commercial calculations inspectable and why a guarantee should not be treated as a technical acceptance test unless its conditions and remedy are explicit. Separate model behavior, operational readiness, and business outcome into different rows and decisions.

Responsibility map: who actually signs each row?

A founder or managing director may sign the commercial decision, but they should not be asked to personally validate every technical fact. The acceptance record should identify one accountable approver and one evidence-producing owner per important row. A business owner confirms that the delivered process matches the need and that exceptions are understandable. A technical owner confirms the release, environment, build or managed-service configuration, access, and recovery path. A privacy or security specialist reviews relevant data and access risks. A contract owner checks rights, support, costs, and the terms that govern unresolved defects.

Small companies may combine these roles. A finance manager might be both business owner and commercial approver; a trusted external engineer might act as technical reviewer. Combination is acceptable if the record says which hat the person is wearing and what they have actually tested. What matters is that “the consultant said it was fine” is not the only evidence. If no one inside the company can test a critical operation, the buyer may choose an independent reviewer or a managed service. The contract should record the chosen dependency, its price, and the route to change later.

A signer should receive a compact decision summary: passed hard gates, failed or untested rows, accepted exceptions, residual risks, next owner, upcoming renewal or support date, and decision to launch, limit, or stop. The full evidence pack can be linked, but a contract owner should not have to infer the recommendation from a folder. The summary makes the decision auditable without pretending that every piece of technical evidence can be reduced to one score.

Mermaid decision path

The flow below separates the existence of an artifact from the buyer’s decision to operate it. A failed gate can lead to rework or a limited non-production acceptance; it should not silently become a production go-live.

flowchart TD A[Freeze scope and release] --> B[Collect artifact by row ID] B --> C{Named recipient can run the test?} C -- No --> D[Record delivery gap and owner] D --> E{Can the supplier cure it?} E -- Yes --> F[Rework and repeat test] E -- No --> G[Negotiate exception, alternative, or exit] C -- Yes --> H{Any hard gate failed?} H -- Yes --> I[Block affected production scope] I --> F H -- No --> J{Evidence complete for weighted rows?} J -- No --> F J -- Yes --> K[Record acceptance and residual risks] K --> L{Operating owner and support route named?} L -- No --> G L -- Yes --> M[Launch within accepted boundary] M --> N[Schedule review after change or incident]

The flow includes an important option: limited acceptance. A company might accept a prototype for internal testing while preventing real customer data or external actions. That should be a written scope restriction and technical control, not a verbal understanding. If the system is turned on in a live workflow before its hard gates pass, the “limited acceptance” branch did not actually happen.

Common failure modes and what to do instead

A folder is mistaken for a transfer. The provider uploads code, manuals, and slides; the customer cannot build the release or locate the active version. Ask the receiver to reproduce a clean setup and record the release identifier. If the product is vendor-hosted, verify the customer’s account, configuration export, support, and exit route instead of demanding source that is not part of the deal.

The final demo is curated by the supplier. The test uses only the examples that the model handles well. Agree the fixture or case-selection rule earlier, include realistic failures, and have the receiving owner choose or approve cases. This still does not prove performance on all future data; it proves the bounded sample was tested.

A business metric changes after the result is known. The team first says “reduce effort,” then after seeing a weak result counts only model runtime and excludes human review. Freeze the formula, window, exclusions, and source records before acceptance. If the original metric is no longer appropriate, record a change request and decide explicitly whether to reset the test.

The risk score hides a stop condition. Eight green documentation rows offset one unresolved access key or missing manual fallback. Keep hard gates outside the score. Do not average away unknown data use, inability to revoke supplier credentials, or a prohibited action that is te...