Milestone invoicing for software projects: Evidence, approval, and payment

Last substantive review: August 2026.

A milestone is not ready to invoice merely because the engineering team says the work is done. The deliverable has to reach the state named in the contract, any required acceptance or other invoice trigger has to be documented, and accounts payable has to receive a correct invoice with the evidence and references it needs. When those events are blurred together, an otherwise healthy software project can end in avoidable payment disputes.

This guide covers the operational path from accepted evidence to payment. It assumes the parties have already chosen a commercial model and designed the milestone scope and acceptance criteria. For those earlier decisions, use Horizon Labs' guides to scoping a fixed-price milestone and outcome-based pricing. This page does not choose between pricing models.

It is operational guidance, not legal, tax, or accounting advice. Contract language, invoice requirements, taxes, revenue recognition, worker classification, interest, retainage, and remedies vary by agreement and jurisdiction. Have qualified legal and finance advisers review the rules that apply to the parties.

Keep six states separate

Most confusion comes from treating “complete,” “accepted,” and “paid” as one status. Use a state model that both delivery and finance can see:

A production deployment can be delivered but still under review. A milestone can be accepted while the invoice is missing a purchase-order number. An invoice can be approved but not yet paid. Preserve those distinctions in the project record instead of arguing from email timestamps.

Design the handoff between delivery and finance

Name the roles before the first milestone reaches review:

• Vendor delivery owner: confirms that the evidence package is complete and submits it.
• Client technical reviewer: verifies the agreed technical and quality evidence.
• Business acceptance authority: accepts, rejects, or accepts with recorded exceptions if the contract allows it.
• Procurement or contract owner: confirms the SOW, purchase order, approved changes, amount, and invoice trigger.
• Accounts payable: validates invoice fields, routing, vendor setup, due date, and payment status.

One person may hold more than one role in a smaller company, but the authority should still be explicit. A product manager who comments on a demonstration is not automatically the contractual approver. A technical reviewer who finds a defect should not unilaterally change the milestone value. Accounts payable should not have to infer acceptance from a project-management board.

Record backup approvers and planned absences. If the only acceptance authority leaves for two weeks on the review start date, the delay is an operating-design failure. The schedule should include the time the client's reviewers reasonably need to perform the agreed tests.

Build one invoice package, not a scavenger hunt

The package should let a new procurement or finance reviewer connect the request for money to the contract and the accepted work without reconstructing the project from chat. Include:

• legal vendor and customer identities, addresses, and required registration or tax information;
• a unique invoice number, invoice date, currency, line amount, total, and payment instructions;
• contract, statement-of-work, purchase-order, and milestone identifiers;
• a plain description of the accepted service or deliverable and the service or delivery date;
• the acceptance record: approver, date, decision, and any accepted exception;
• links to the immutable evidence index, approved change orders, and relevant delivery record;
• the agreed payment term and the destination specified by procurement or accounts payable;
• a contact for invoice questions that is different from a generic sales inbox.

The exact required fields depend on the parties and jurisdiction. For a concrete public example, the UK government's invoice guidance lists a unique identifier, supplier and customer details, a clear description, supply and invoice dates, amounts, applicable VAT, and total owed. Those are UK requirements, not a universal template. Use local advice and the client's onboarding instructions.

U.S. federal procurement provides another useful operating model without governing an ordinary private software contract. FAR 32.905 separates a proper invoice from the receiving report or other authorization to pay and names the identifying, delivery, acceptance, and official information those records contain. The transferable lesson is simple: the invoice and the acceptance record are connected records, not substitutes for each other.

Create an evidence index for each milestone

The invoice should not embed every screenshot and test log. Link to a stable evidence index with permissions that will remain available through review and audit. A software milestone index may include:

• the accepted criteria and the version of the SOW or change order that defines them;
• release, build, commit, artifact, environment, or feature-flag identifiers;
• a demonstration record and the date the reviewer received usable access;
• test results, migration reconciliation, accessibility or security evidence where applicable;
• known defects, accepted limitations, deferred items, and their disposition;
• deployment and rollback evidence when production delivery is part of the milestone;
• the acceptance decision, comments, and identity of the authorized approver.

Evidence must correspond to the criterion. A pull request does not prove that a user workflow works. A recording does not prove a data migration reconciled. A green test suite does not prove an external approval was received. Keep technical detail proportionate, but do not replace acceptance with ceremony.

Run the workflow in a fixed order

1. Pre-register the milestone. Confirm its identifier, amount, invoice trigger, acceptance authority, reviewers, evidence location, review window, AP destination, purchase-order status, and dependencies.
2. Submit a completion notice. The vendor delivery owner states what was delivered, where it can be inspected, which criteria are met, and which exceptions remain.
3. Confirm review access. Start the operational review clock only when reviewers have the environment, credentials, data, and instructions required by the agreement.
4. Collect one decision. The acceptance authority records accepted, rejected with criterion-based reasons, or another contractually permitted state. Consolidate reviewer feedback before returning it.
5. Cure and re-verify if needed. Link each correction to the rejected criterion and submit new evidence. Preserve the earlier review record.
6. Record acceptance. Capture milestone, accepted version, date, authority, exceptions, and any related change orders.
7. Validate a draft invoice. Delivery and procurement compare the amount, references, dates, legal fields, routing, and acceptance record before finalization.
8. Finalize and send. Issue the invoice through the contractually required system or address and record receipt when the system supports it.
9. Track approval and due date. Log questions, corrections, approval-for-payment state, and the date the applicable agreement or rule makes payment due.
10. Reconcile payment. Match remittance to the invoice, record partial or short payment, and close or escalate the remaining balance.

This sequence need not create ten meetings. Most steps are status transitions with evidence. What matters is that the team cannot finalize an invoice while the trigger is still ambiguous and cannot silently rewrite an accepted record to fix an invoice error.

Set review and payment timing in the operating calendar

There is no universal five-day acceptance window or Net 30 term for software projects. The signed agreement and applicable law control. The parties should still put the operational dates on one calendar: expected delivery, reviewer availability, review start, response deadline, cure window, acceptance date, invoice submission, invoice receipt, due date, and expected payment run.

Define which event starts each clock. Is the review window measured from email delivery, usable staging access, production release, or receipt of the complete evidence package? Does the payment term begin on invoice date, receipt of a proper invoice, acceptance, or the later of two events? If the answer is not visible, finance and delivery will calculate different dates.

FAR 32.904 illustrates why both invoice receipt and acceptance dates matter: its federal payment rules calculate many due dates from the later of a proper invoice and government acceptance. A private company should not copy the federal timing rule unless it applies, but it should name its own trigger just as clearly.

“Deemed acceptance” is a legal term with contractual consequences, not a project-management shortcut. Do not insert or enforce it based on a blog template. If counsel approves such a clause, the operating record should show the delivery event, complete evidence, notice, deadline, objections, and the exact state reached under the agreement.

Keep change handling outside the acceptance record

A requested change does not make the original milestone undefined. Record whether it is:

• a correction required to meet an existing criterion;
• new scope that needs a change order, amount, and schedule;
• a client dependency or approval that arrived late;
• a third-party event outside either delivery team's direct control; or
• an accepted limitation or deferred item permitted by the contract.

Do not edit the original criterion after delivery and call it clarification. Preserve the version reviewed, then approve a change. If the unchanged portion is independently usable and the contract permits partial acceptance, record its amount and evidence. Otherwise keep the milestone open. Finance should never invent a percentage allocation after a disagreement begins.

When a dependency fails, update the forecast and decision log without falsifying delivery history. A vendor may have completed its work while production release waits on a client security review. Whether that event triggers acceptance or payment depends on the agreement, not sympathy for either side.

Use holdbacks deliberately

A holdback delays payment of a stated amount until stated release conditions are met. It is not a universal feature of software invoicing and there is no responsible default percentage. If the parties use one, define:

• the amount or calculation and which invoice carries it;
• the release event, date, and authorized approver;
• the defect severity or other condition that can delay release;
• the evidence required to request and approve release;
• whether partial release is possible;
• what happens when the release decision is disputed.

A large undefined final holdback can turn every minor issue into leverage over unrelated accepted work. It can also cause the vendor to finance the engagement. If the concern is post-launch defects, a defined warranty may address that risk more directly. Procurement and counsel should decide which mechanism fits.

Separate acceptance, warranty, and support

Acceptance says the milestone met its agreed trigger at a point in time, subject to the contract. A warranty defines responsibility for qualifying defects after the stated start event. Support covers operating help, incidents, questions, or changes under its own terms. They can be related, but they are not the same obligation.

For qualifying Horizon Labs product-team work at $100–120 per hour, the coordinated team covers full-stack engineering, QA, launch, and a six-month code warranty under the signed statement of work. The SOW defines which work qualifies, when the warranty starts, how a defect is reported and reproduced, response or remedy process, and exclusions. New features, changed requirements, third-party behavior, or operating-environment changes are not automatically warranty defects.

Invoice timing should not silently redefine the warranty. If acceptance occurs before launch but warranty begins at production release, say so. If several milestones contribute to one release, identify whether each has its own warranty start or the product has one. Do not leave finance to infer the date from the final invoice.

Horizon Labs' $150–200 per hour senior or specialist lane applies when an inherited system or technically difficult area makes diagnosis or acceptance evidence itself the valuable work. A bounded milestone might be a reproducible failure, an architecture decision, an implemented patch with tests, or a recovery runbook. It should not promise that a legacy backlog will disappear by a date or that one intervention will produce a business outcome.

Keep an audit trail that survives staff turnover

Use stable identifiers across the SOW, milestone, delivery record, acceptance, change order, invoice, credit or correction, payment, and warranty ticket. Record who changed each state and when. Do not overwrite a rejection with acceptance or edit a finalized invoice to hide an amount error.

Invoice tools have their own state rules. Stripe's invoice lifecycle documentation, for example, distinguishes draft, open, paid, void, and uncollectible states and explains that finalization makes certain invoice fields immutable. That is Stripe's implementation, not a universal accounting rule, but the pattern is useful: validate while the invoice is a draft; after finalization, correct it through the supported record rather than editing history.

The U.S. GAO's 2025 Green Book is a federal internal-control standard, not a private-company mandate. It nevertheless offers a sound control principle: define the controls, documentation, information, and monitoring needed to run operations and produce reliable records. For milestone invoicing, that means separating authorization where risk warrants it and retaining enough evidence to trace the transaction.

Resolve objections against the record

An invoice objection should identify the invoice line, milestone, contractual requirement, evidence reviewed, and requested correction. “We are not happy yet” is not actionable. Neither is “the team worked hard.” Bring the discussion back to the accepted state, the invoice fields, and any approved change.

Route technical rejection to the acceptance authority, invoice-format errors to finance, contract interpretation to the contract owners and counsel, and payment execution to accounts payable. One person can coordinate, but the decision should stay with the authorized role.

If the invoice amount or legal fields are wrong, follow the invoicing system and jurisdiction's correction process. Depending on the system and rules, that may mean voiding and reissuing or using a credit note. Do not give accounting treatment from the delivery channel. Preserve the original, correction, approval, and communication.

Do not hold unrelated accepted invoices hostage to a new dispute unless the agreement permits it. Track disputed and undisputed amounts separately where counsel and finance approve that approach. Keep delivery decisions and payment remedies in their proper records.

Use one milestone-to-payment register

The register is an index, not the sole evidence repository. Restrict sensitive financial and contractual information appropriately. Preserve access for the people who must answer a question after the delivery team changes.

Common operational failures

• The vendor sends an invoice before the named trigger and expects the project manager to create acceptance afterward.
• The client accepts in a meeting, but no authorized record reaches procurement.
• The invoice description says “development services” and cannot be matched to a milestone or purchase order.
• Review starts before the client has working access, so each side calculates a different deadline.
• New scope is added to the rejection list instead of entering change control.
• A holdback has no objective release event.
• Acceptance, warranty, and support are treated as one undefined promise.
• Finalized invoice history is edited or scattered across email, chat, project boards, and accounting software.

The fix is not a more elaborate billing tool. It is a shared state model, named authority, complete evidence, and a traceable handoff between delivery, procurement, and finance.

How Horizon Labs fits

Horizon Labs can structure the delivery evidence and operating handoff for a product-team milestone while the client's legal, procurement, tax, and accounting advisers control their domains. Before work starts, the parties should agree on the SOW reference, evidence package, acceptance authority, invoice trigger, AP route, warranty boundary, and change process. Before each invoice, delivery and finance should verify that the record matches those terms.

If your company is preparing a software milestone schedule or repairing an invoicing process that produces recurring disputes, contact Horizon Labs. Bring the current SOW, milestone register, acceptance path, invoice requirements, and one recent example. The useful output is a cleaner operational path—not a legal opinion or an accounting conclusion.

Sources used

• U.S. Federal Acquisition Regulation 32.905: Payment documentation and process
• U.S. Federal Acquisition Regulation 32.904: Determining payment due dates
• U.S. Federal Acquisition Regulation Part 46: Quality assurance and acceptance
• UK government: Invoice information requirements
• Stripe documentation: Invoice status transitions and finalization
• U.S. GAO: 2025 Green Book internal-control standards

Frequently asked questions

What should a milestone invoice package include?

Include the invoice, contract or statement-of-work reference, milestone ID, accepted deliverable description, delivery and acceptance dates, acceptance authority, evidence links, approved change orders, known exceptions, amount, tax treatment supplied by the appropriate finance adviser, payment instructions, and the correct procurement or accounts-payable routing details.

When should a milestone invoice be issued?

Issue it when the contract's invoice trigger has occurred and the required acceptance or approval record exists. Delivery, acceptance, invoice receipt, payment approval, and payment are separate events. The signed agreement and applicable rules control their timing; there is no universal review window or payment term.

What happens when a client accepts only part of a milestone?

Use partial acceptance only if the contract permits it and the accepted portion has its own amount and evidence. Record what was accepted, what remains open, and whether a change or cure is required. Do not invent an allocation after the fact or mark the whole milestone accepted to simplify billing.

Is a holdback the same as a software warranty?

No. A holdback delays payment of an agreed amount until stated release conditions are met. A warranty defines responsibility for qualifying defects after the specified start event. Neither automatically covers new scope, third-party changes, support, or operating-environment changes; the signed contract must define each boundary.

How does Horizon Labs handle milestone invoices and warranty?

For qualifying product-team work at $100–120 per hour, Horizon Labs coordinates full-stack engineering, QA, launch, and a six-month code warranty under the signed statement of work. The SOW defines milestone evidence, invoice triggers, acceptance, warranty start, coverage, process, and exclusions. Senior or specialist work at $150–200 per hour uses bounded evidence appropriate to inherited or technically difficult work and carries no guaranteed speed or outcome.