Software Acceptance Checklist: How to Verify Vendor Delivery

What Acceptance Has to Confirm Before You Sign Anything

The most common failure in accepting custom software is judging the result on a single dimension. The screens work, so the project is done. Four months later the same project is judged again, this time on the cost of every small change, the time the support team spends reconciling records by hand, and the fact that only one person knows how to deploy it. Both judgments are about the same delivery. Only one of them was made while you still had leverage.

A delivery can pass one dimension and fail another without anyone noticing at the time. This section sets the vocabulary the rest of the article uses, so keep it in mind when you read the checklists further down, whether the system came from your in-house team or from an external web development partner.

Business Suitability, Technical Quality and Operational Capability

Business suitability means the process can be completed end to end by the people who do it every day, including the cases they dislike. A partial stock situation, a customer who needs a non-standard discount, an order cancelled after the warehouse already started picking. The happy path is the easiest part of any system to build and the least informative part to test.

Technical quality means the agreed properties hold under the agreed conditions: response time on the operations that matter, access control that separates one customer from another, a codebase that can absorb a change safely. Product quality is multidimensional by construction, which is why the international product quality model published as ISO/IEC 25010 describes quality as a set of characteristics rather than a single verdict. We reviewed the public abstract of that standard, not the full paid text, and we make no claim of conformance or certification here. The useful takeaway is structural: if your acceptance criteria only describe functions, you have written down one characteristic and left the rest to chance.

Operational capability means your side can deploy, monitor, support and recover the system. It is the dimension buyers most often discover they are missing, because it is invisible while the vendor is still engaged and answering the phone.

What UAT, Technical Assessment and Handover Each Prove

User acceptance testing (UAT) answers one question: does the business process work for the people who own it. It is run by business users on realistic data, and it can legitimately include non-functional expectations, such as whether the Monday report finishes before the sales meeting starts. UAT is not an interface review, and treating it as one is how companies end up accepting software that looks right and works wrong. Visual polish is a conversation to have with the web design agency before the build, not a substitute for checking the process.

Technical assessment answers a different question: do the agreed properties hold, and what will this system cost to run. Handover answers a third: can our side take the system over at all.

We separate the three so that responsibility and evidence are distributed clearly, not because they are in conflict. The ISTQB Certified Tester Acceptance Testing syllabus makes the same point from the tester's side: acceptance work depends on early, continuous collaboration between business analysts, product owners and testers, with criteria defined before the build rather than reconstructed after it. In practice that collaboration is what turns a business expectation into something two different people can check and agree on.

Each of the three produces a different kind of evidence: scenario results signed off by process owners, measurements and logs from the technical checks, and a working deployment performed by your own engineer. A gap in any one of them is a gap in the acceptance decision, even if the other two look excellent.

Turning Business Expectations into Criteria You Can Actually Test

Most disputed deliveries trace back to a requirement written as an intention. "Orders are placed on the portal" is an intention. Two honest people can read it, look at the same system, and reach opposite conclusions about whether it is satisfied. The vendor sees an order reaching the ERP. The sales manager sees an order that still needs a phone call to confirm the delivery date.

A criterion is testable when someone other than its author can run the check and get the same answer. That is the whole bar. It does not require formal notation, a testing tool, or a QA department. It requires a concrete condition, a concrete action and a concrete expected outcome that can be observed somewhere other than in the mind of the person who wrote it.

Connect Requirement, Check and Evidence in One Acceptance Matrix

The single most useful artifact in acceptance is a matrix that links each business requirement to the way it will be verified and to the person who owns the verdict. This is requirements traceability in its plain form: every requirement can be followed forward to a check and a piece of evidence, and every piece of evidence can be followed back to a requirement. Test evidence means an observable record that the check happened and what it produced.

The rows below come from the illustrative wholesale scenario. They are written as an example to copy the shape, not as a description of a Webdelo client project.

Notice what counts as evidence in that table. A screenshot of a green confirmation screen is the weakest kind, because it shows what the system said about itself. A record in the receiving system and an entry in the exchange log are stronger, because they show what actually happened downstream. Whenever you have the choice, prefer evidence produced by the system under test and readable by someone who did not run the check.

Filling this matrix before testing starts changes the tone of the whole engagement. Disagreements move from the end of the project, where they are expensive and personal, to the beginning, where they are cheap and technical.

Recovering Criteria Nobody Wrote Down

The realistic situation is less tidy: the project is nearly delivered and nobody ever agreed on criteria. This is common, and it is recoverable. It is not a reason to accept whatever arrives.

Work through it in three steps. First, collect what was actually agreed: the original specification, the approved change requests, meeting decisions that both sides acted on. Second, rank the critical business operations by the damage their failure would cause, and write criteria for those first. In the illustrative scenario that list is short: order submission, pricing and approval, transfer to the warehouse, customer data separation. Third, take everything left over and split it into two lists that must never be mixed.

• New requests. Things nobody agreed to build. They may be valuable and they may be urgent, and they still belong to a next phase with its own budget.
• Contested expectations. Things one side believed were included and the other did not. These need a decision, not a defect ticket.

The split matters commercially. Filing a new request as a defect tells the vendor that your defect list cannot be trusted, and from that moment every real defect you report is negotiated instead of fixed. When criteria were never agreed at the start, a structured discovery phase before the next stage is usually cheaper than another round of reconstruction after it.

"I recommend discussing acceptance criteria with the person who owns the process daily. In a requirement like 'order is placed', important rules are often invisible: who approves a non-standard discount, what happens when stock is partial, when an order is considered handed off to the warehouse. If these rules aren't written down, you can successfully test a function and still receive a process that staff have to complete manually."

Dmitri Cercel

Tech Lead, Software Architect

The practical instruction inside that quote is about who you interview. Sponsors describe the process as it is supposed to work. The person who runs it every day describes the exceptions, and the exceptions are where the unwritten rules live. Budget two or three hours with that person before criteria are frozen, and ask them what they do when something goes wrong rather than what they do normally.

Deciding Who Checks What, and Which Build They Check

Two failures look completely different from the outside and are the same failure underneath. In the first, everyone tested diligently and nobody owns the verdict, so the acceptance meeting produces a discussion instead of a decision. In the second, everyone tested a slightly different build, so a defect that one person reproduced yesterday cannot be reproduced today and the argument shifts to whether it was ever real.

Both are prevented by decisions made before testing starts, and both are almost impossible to repair afterwards.

Who Validates, Who Verifies and Who Accepts Residual Risk

Three distinct responsibilities, each belonging to a named person rather than a department.

• The business process owner confirms that the scenarios reflect how the work is really done and that the outcome is usable by their team. In the illustrative scenario this is the head of sales operations, not the IT manager.
• QA and the technical team design the checks and produce evidence, including the non-functional ones: measurements, access tests, deployment results.
• An authorized manager accepts residual risk. Residual risk is the known, described exposure you consciously agree to carry: the integration that could not be tested against the real third-party system, the load level nobody measured, the module with no automated checks. It never reaches zero, and pretending otherwise just moves it out of sight.

Write the three names on the acceptance plan. "IT will confirm" is not an owner, and in practice it means the verdict will be made by whoever is least able to refuse it.

Fix the Build, the Environment, the Data and the Known Limits

A release candidate is a specific build proposed for acceptance, identified precisely enough that anyone can tell whether they are looking at it. Record four things before anyone starts testing.

• The build. Exact version or build identifier, the configuration applied, and the state of any feature flags. If a new build appears mid-acceptance, that is a decision to make openly, not a background event.
• The environment. Which external systems are real, which are simulated, which are simply unavailable. This determines what your conclusion can cover.
• The data. Realistic anonymized or synthetic data with the volume and the awkward shapes of production: long customer names, multi-position orders, expired price lists. Three rows named "test" prove nothing.
• The limits. What this round of acceptance will not cover, and why. Stating limits in advance keeps them from being discovered later as accusations.

The output is a one-page acceptance plan: participants and their roles, the release candidate, the environment, the data, the entry conditions under which testing may begin, and the known limits. Without a fixed build, a fixed defect is unverifiable and a passed test is unrepeatable, which means the evidence you collect cannot support a decision.

Testing Complete Business Workflows, Including the Awkward Ones

A feature test asks whether a button works. A scenario test asks whether the company got the business outcome. The gap between those two questions is where most accepted-and-then-regretted systems live, because every individual component can report success while the business result is wrong.

The scenario below is illustrative: a wholesale company running a B2B portal for its customers, an ERP for orders and inventory, and a separate warehouse system for picking and shipping. The shapes transfer to other setups even when the systems differ.

Follow One Order from the B2B Portal Through ERP to the Warehouse

Trace a single order along its entire path and check the business result at each hop. The customer places the order on the portal. Pricing rules apply, including the customer's contract prices and volume tiers. Approval rules apply where the discount exceeds the threshold. The order reaches the ERP and becomes a real document with a real number. The warehouse system receives a picking task. Statuses travel back so the customer and the sales team see the same state of the same order.

At each hop, verify the outcome rather than the message. Correct prices in the ERP, not merely a successfully delivered message. The picking task containing the right positions in the right quantities. The status visible to the customer matching the status visible to the sales manager. Include the approval branch deliberately, because approvals are where "it worked in the demo" usually ends: demos are recorded on the path that has no approval in it.

Cancellations, Retries and Unavailable Integrations

This is the part of acceptance that pays for itself, and it is the only place in this checklist where integration failure is covered. Work through it fully here.

• Cancel late. Cancel an order after it reached the ERP, then cancel another after picking has already started. Check what every system believes afterwards: the portal, the ERP, the warehouse, and the stock reservation. A cancellation that leaves stock reserved in one system and free in another produces a shortage nobody can explain a week later.
• Retry. Submit the same order twice, through a double click, a page refresh and a network timeout followed by a client retry. Duplicates are the classic mid-market damage: a second ERP document becomes a second picking task becomes a second physical shipment, and the cost lands on the customer relationship as much as on the logistics budget.
• Break the connection mid-flow. Take the ERP offline while an order is in transit. Does the operation queue and retry, fail loudly with a visible message and an owner, or disappear silently? Silent loss is the worst outcome and the most common one. Then bring the ERP back and check that the exchange recovers and reconciles rather than replaying everything and double-posting.
• Check the partial case. Stock covers half the ordered quantity. Does the system split the order, hold it, or ship what it has? Whatever the answer, it must be the answer the business actually wants, written down in advance.

State the consequence of each failure in the terms your management understands: orders lost between systems, duplicate shipments returned at your cost, and hours of manual reconciliation every week that quietly become somebody's permanent job.

Reconcile the Migrated Data

Matching row counts is not reconciliation. A migration can move every row and still break the relationships that make the rows meaningful. Check four things specifically: customer-to-contract links, price lists and customer discounts, open orders that were mid-flight at the cutover moment, and the historical totals your reporting depends on. Then take a sample of real records and follow each one end to end, from the old system to the new one to the report that uses it.

Record every scenario on a card with the same five fields: preconditions, action, expected result, actual result, evidence. Twenty of those cards are worth more than a hundred-page test report, because each one can be re-run by a different person on a later build.

A workflow is accepted when the outcome is correct in every connected system, not when each system separately reports success. That distinction is the difference between a working integration and a set of components that agree to disagree.

Technical Properties That Decide What the System Costs You Later

Functional correctness determines whether you can launch. The properties in this section determine what you pay for the next three years, in infrastructure bills, in the price of every change request, and in the time your people spend working around the system. These are the characteristics that the ISO/IEC 25010 product quality model treats as dimensions in their own right: performance efficiency, security, maintainability. They are harder to check than features, which is exactly why they are usually skipped.

Performance Under an Agreed Workload

Define the measurement before you measure anything: which operations, on what data volume, with how many concurrent users, at which point in the business day. A performance result without those four parameters is a number without a meaning.

Refuse universal response-time targets. "Every page under two seconds" sounds rigorous and decides nothing, because the right target comes from the operation and the process around it. In the illustrative scenario, two measurements matter far more than the rest: order submission during the seasonal peak, when the portal carries several times its normal traffic, and the report the sales team runs every Monday morning over twelve months of history. If those two hold on production-sized data, the system is usable. If they were measured on an empty database, the measurement means nothing. Where the portal also exposes public pages, the same response times feed into SEO results in the USA market, so measure them on the public side as well.

Access Control and Relevant Application Security Requirements

Check the security requirements you agreed on, with priority on cross-customer and cross-tenant access. In a B2B portal that is the failure with the highest business cost: one customer seeing another customer's contract prices ends commercial relationships. Run the check through the interface and through the API, because the API is where it is usually skipped. An interface that hides a button does not stop a request that asks for the data directly.

For a structured list of requirements to select from, the OWASP Application Security Verification Standard is a practical public reference, with 5.0.0 listed as the stable version on the project page. Use it to choose requirements appropriate to your product and its risk, and name the version whenever you cite an individual requirement in your acceptance documents.

State the limit of the result honestly in the acceptance record: a selective check is evidence about what was checked. It is never proof that no vulnerabilities exist, and any document that implies otherwise creates a false sense of closure.

Maintainability, Supported Dependencies and Operating Cost

Four things to look at, each with a business consequence you can state in a sentence.

• Dependencies. Are the frameworks and libraries still receiving updates, and is any of them already past end of support? An unsupported dependency becomes a forced migration on someone else's schedule.
• Technical constraints. Which foreseeable changes does the current design make expensive? Adding a second warehouse, a second currency, a second legal entity. Ask the question while the vendor is still available to answer it.
• Automated checks. Is the business-critical logic covered by automated tests, specifically the pricing rules, the approval routing and the exchange with the ERP? Coverage of trivial code is not the point.
• Cost assumptions. What data volume, traffic and retention period does the infrastructure estimate assume, and what happens to the bill when the real numbers are twice that?

We disagree with the common practice of judging maintainability by code comments and formatting. Consistent formatting is easy to produce and tells you almost nothing about the cost of change. Judge maintainability by whether a change to critical logic can be made and verified safely, by someone who did not write the original code.

Record the result as a technical risk table, one row per risk, so the decision is visible next to the evidence.

Every row in that table is a decision someone made on purpose. That is the entire value of writing it down: six months later, nobody has to reconstruct whether a known problem was missed or accepted.

Checking That the System Can Be Handed Over at All

Handover and launch readiness are different checks with different evidence, and merging them is how companies end up with a system they own on paper and cannot touch in practice. Handover proves that your side received the means and the knowledge to work with the system. Launch readiness, covered in the next section, proves that your company can operate it and survive its failures.

Repositories, Service Accounts and Technical Materials

Verify actual access, not a list of promised access. The difference is a person from your side logging in while someone watches the screen.

• Code and pipelines. Repository with full commit history, not a single squashed import. CI/CD configuration, build pipelines, artifact registries.
• Infrastructure and accounts. Cloud and hosting accounts, domains, TLS certificates, third-party API keys, service accounts and their credentials.
• Ownership. Accounts registered to your company's addresses and billing, not to a developer's personal email. This is the item most often discovered months later, at the worst possible moment.
• Materials. A dependency inventory, build and release instructions, a configuration reference explaining what every setting does, and an architecture overview detailed enough to plan a change.

A software handover checklist that lists documents without verifying access describes an intention. Log in to each item, from your own account, before the vendor's engagement ends.

Can the System Be Deployed Without Undocumented Developer Knowledge

There is one test that settles this question, and it takes an afternoon. An engineer from the receiving side deploys the agreed build into a separate environment using only the delivered instructions. No calls, no screen sharing, no "just ask Andrei where the config lives".

Record every point where they had to ask the author. Each one is a documented gap with an owner and a deadline, and each one would otherwise have surfaced during your first production incident. Handover is complete when the knowledge moved, not when the document count looks satisfying.

"I would conclude any handover with a deployment rehearsal: a member of the receiving team deploys the agreed version in a separate environment using the provided instructions. If they need to ask the author where to find a configuration or which step to run manually, that gap must be closed before the handover is complete. This check shows how well operational knowledge was transferred, though it does not prove the quality of the overall architecture."

Dmitri Cercel

Tech Lead, Software Architect

The honest limit stated at the end of that quote is worth keeping. A successful rehearsal tells you the operational knowledge transferred. It says nothing about whether the architecture will hold under a change you have not yet requested. Those are separate questions with separate evidence, and this one happens to be cheap to answer.

Getting the Company Ready for Launch and for Things Going Wrong

A launch review examines dependencies, capacity and failure modes before a system carries real business. The practice is described in detail in the Google SRE chapter on reliable product launches at scale, and the principle scales down cleanly even though the infrastructure does not. A mid-sized wholesale company is not importing Google's operational model. It is borrowing one question: what does this system depend on, what happens when each dependency fails, and who finds out.

Support Ownership, Monitoring and User Preparation

Three commitments have to exist before go-live, each with a name attached.

• Support ownership. A named owner for incoming issues, a working intake channel that users actually have access to, and an agreed response expectation inside business hours. "Email the vendor" is not an intake channel once the project is closed.
• Monitoring that reaches a human. Decide which failures notify whom. The specific case to design for: the exchange with the ERP stops working at 09:00 and somebody knows before the first customer calls at 11:00. An alert that lands in a mailbox nobody reads is equivalent to no alert.
• User preparation. Instructions in the language people work in, a short session for the process owner's team on the scenarios they will run daily, and a known contact for the first week. Operational readiness includes the people, and this is the cheapest part of it.

Rehearse Recovery and Write Down What Rollback Cannot Undo

A backup that has never been restored is an assumption, not a control. Rehearse the restore into a separate environment, time how long it takes, and check that the restored data is actually usable. The number you get is what your business continuity plan is really based on.

Then write down the thing most buyers miss: reverting to the previous version of the code does not revert data. Orders taken after go-live, statuses changed, records migrated and edited stay changed. A rollback returns the software, not the week. Define the rollback window explicitly, say what happens after it closes, and accept that after that point the only path is forward fix.

The output is two short documents: a launch plan and a failure plan. Each names owners, a decision point, and a cut-off time by which the decision must be made. A failure plan written during the failure is written badly.

Turning Test Results into an Accept-or-Fix Decision

The decision is not a percentage of passed tests. That number is the most quoted metric in acceptance and one of the least informative, because it weighs a misaligned label on a settings screen the same as an order disappearing between two systems. Ninety-four percent passed can describe a healthy delivery or an unusable one.

Rank Defects by Business Impact, Not by Ticket Count

Defect severity here means business damage, multiplied by how often the situation occurs, adjusted for whether a workaround exists. It is a business judgment, not a QA-internal label. Three bands, with examples from the illustrative scenario.

• Blocking. An order accepted on the portal never reaches the ERP, and nobody is notified. The business loses revenue and trust, and discovers it from the customer. No workaround that scales.
• Serious. A customer can see another customer's contract pricing through the API. Rare in normal use, severe in consequence, and it cannot be managed by asking users to be careful.
• Minor. A misaligned label on an internal settings screen used twice a month. Real, worth fixing, and not a reason to delay anything.

One rule deserves to be stated flatly, because it is violated constantly: an untested area is not a passed area. If nobody checked the returns process, the acceptance record says the returns process was not checked, names an owner and sets a date. It does not say the system passed.

Confirm Fixes and Check the Workflows the Fix Touched

A developer's "fixed" is a claim. Confirmation testing turns it into evidence: re-run the original failing check on the new build, under the original conditions, and record the result. The same person who found the defect should ideally confirm it, using the same scenario card.

Regression testing covers what the fix might have disturbed elsewhere. In the illustrative scenario, a fix to order cancellation calls for re-checking stock reservation and status return to the portal, because all three touch the same order state. Deciding which workflows to re-check is a technical judgment, and it should be made by someone who knows what the change touched rather than by a fixed ritual.

Always record which build the confirmation ran on. Evidence without a build identifier is unattached and cannot be used in a decision two weeks later.

Record Acceptance Status Separately from Go-Live Authorization

Use three technical statuses and nothing softer: ready, ready with stated limitations, not ready. The middle one carries the real content, so for every open issue record five fields: impact, owner, deadline, workaround, and the condition under which it will be re-checked.

Go-live authorization is a separate record and a separate decision. It adds what acceptance does not measure: operational readiness, user preparation, the transition window, and whether the business can absorb disruption in the chosen week. A delivery can be technically ready in March and authorized for go-live in May because March is the seasonal peak. This is a recommendation about sequencing management decisions, not a statement about the legal effect of sign-off.

A verified build can legitimately wait. Keeping the two records separate is what makes that wait a decision with an owner instead of a delay nobody wants to explain.

What to Review After the First Full Business Cycle

The problems that surface in month four are rarely the ones a demo could have shown. They come from volume, from the calendar, and from the specific combination of exceptions that only real customers generate. That is why acceptance has one more checkpoint after go-live.

Define the cycle by the business rather than the calendar. A full order-to-invoice round including returns, a month-end close, a seasonal peak: whichever pattern represents the company's real load. In the illustrative scenario it is the first month that contains both a month-end close and a promotional week driven by the company's digital marketing calendar.

Compare Real Operation with the Assumptions You Accepted On

Go back to the assumptions recorded in the acceptance plan and the technical risk table, and compare each one against observation.

• Which failures actually occurred, how often, and how were they detected? Detection by customer complaint points at a monitoring gap, not only at a defect.
• What load did the system really carry against the workload that was tested?
• What did the infrastructure actually cost against the estimate, and which assumption was wrong?
• Where are users working around the system by hand?

The last one is the highest-value signal in the whole review. A spreadsheet that someone maintains in parallel, a status updated by phone, an order form re-keyed into the ERP: each of these usually traces back to an unwritten process rule of exactly the kind the first expert opinion described. Find the rule, write it down, and decide whether it belongs to stabilization or to a next phase.

Close the Remaining Defects and Separate Genuinely New Needs

Produce two lists and keep them apart for the same reason as before. Stabilization items belong to the delivered scope and to the current engagement. New business needs belong to a next phase with their own estimate and their own decision. Mixing them makes the vendor defensive about real defects and makes your backlog impossible to plan.

Thorough acceptance does not guarantee that nothing will need rework. Systems change because businesses change. What acceptance does is reduce the number of surprises you pay for twice, and move the remaining ones into a list that somebody owns.

When to Bring in an Independent Technical Reviewer

Most mid-sized companies do not have an in-house specialist who can evaluate a delivery they did not build. That is a normal situation, not a management failure, and bringing in a third party is a reasonable response to it.

Four grounds justify an independent review clearly enough to defend the cost.

• You have no internal technical competence in this stack, so nobody on your side can read the evidence.
• The product carries critical business risk or holds customer data whose exposure would be commercially serious.
• The handover is complex or contested, and the two sides disagree about what was delivered.
• The evidence offered for readiness is thin, unverifiable, or consists mostly of assurances.

A useful review delivers five things: the scope actually examined, reproducible findings with the steps to reproduce them, the business consequence of each finding, a priority order you can act on, and a plain statement of what the conclusion does not cover. The last item is the mark of an honest reviewer, and the same expectation applies to any adjacent review you commission, from a penetration test to an SEO site audit.

Watch for the failure mode. A review that reads as a list of style complaints about the code tells you nothing about readiness and puts your vendor relationship under strain for no benefit. Ask any prospective reviewer how they will tie each finding to a business consequence before you engage them.

Webdelo works with mid-market B2B companies in the US and Germany on requirements alignment, QA and technical assessment of delivered systems. If you are approaching acceptance on a specific project, we are glad to discuss the criteria that matter for your business-critical processes and the realistic scope of verification, starting from the materials you already have.

Frequently Asked Questions

How should acceptance work for phased deliveries?

Each phase needs its own boundary: the list of business operations it covers, the criteria for those operations, and the evidence that closes it. Accept each phase on its own terms, and record the statuses separately so a limitation in phase two does not silently reopen phase one. Add one item that is easy to forget: re-check the interfaces between the new components and everything accepted earlier, because a later phase frequently changes shared data structures. Before go-live, run at least one end-to-end check across all delivered phases together, since nobody has tested the assembled whole until that moment.

How should unavailable third-party systems affect the scope of the conclusion?

A simulated integration can prove that your side builds the right request, handles the documented responses, and behaves correctly on errors it was told to expect. It cannot prove the real exchange works, because the real system's behavior under load, its actual error formats and its undocumented quirks are exactly what a simulator does not reproduce. Record this explicitly as a stated limitation in the acceptance status, not as a passed check. Then create a verification task for the real exchange with a named owner, a deadline and a defined check, and treat the gap as residual risk that somebody accepted on purpose until it is closed.

What determines the duration of acceptance testing?

Four factors set the timeline: the number of business-critical processes in scope, the availability of the people and environments needed to test them, the quality of the original requirements, and how many fix-and-recheck cycles the delivery turns out to need. The last factor is the least predictable and usually dominates, because each cycle adds a fix, a confirmation and a regression check. No universal duration exists, and any number quoted without knowing your scope and your requirements is a guess presented as a schedule. Estimate it the same way you would estimate any other work: by listing the checks, the participants and the cycles you realistically expect.