Acceptance criteria decide when done happened, not the invoice date
An invoice date marks a payment, not a finished feature. This post argues that written, testable acceptance criteria, agreed before work starts, are what actually define done.
A fixed price quote tells you what a project costs. It does not tell you when the project finishes. Studios that skip acceptance criteria often let the invoice date quietly stand in for completion, when the two are not the same thing at all.
That substitution causes trouble later. An invoice is a billing event. It says a milestone was reached according to a payment schedule, not that a feature works the way you expected it to. If the two dates happen to line up, that is coincidence, not proof.
What acceptance criteria actually do
Acceptance criteria are a written list, agreed before work starts, describing what each feature must do to count as finished. Not a general description of the goal, but specific, testable statements. A checkout form is not done because it exists on the page. It is done when a customer can enter a card, see an error on a failed payment and receive a confirmation email on success.
Written this way, criteria remove the guesswork from a handover. You are not asking a studio to agree with your feeling that something looks right. You are checking a list that both sides signed off before a single line of code was written.
The invoice tells you when payment happened. Acceptance criteria tell you when the work did.
Writing them before the brief closes
The right time to write acceptance criteria is during scoping, not after delivery. Once a studio starts building against a fixed price, criteria written retroactively tend to bend towards whatever was actually shipped. That protects nobody. Set them early, and both sides negotiate against a shared definition rather than a target that moves with the build.
For each feature in your brief, write down the conditions under which you would call it finished. Include the unhappy paths, not just the ideal one. What happens when a form is submitted twice, or a payment fails, or an uploaded file is the wrong size. These are the cases that reveal whether a feature was built with care or built only to look finished in a demo.
When a milestone is invoiced, treat that as a separate question from whether it passes its criteria. A studio can reasonably invoice on a schedule tied to calendar dates or work completed, while acceptance still depends on the criteria being met. Keeping these two ideas apart protects you from paying for something that only resembles what you asked for.
At Yunaris we write acceptance criteria into the brief before quoting a fixed price, so you know from the outset what finished looks like, and so does the person building it. Ask any studio you work with to do the same. If they cannot describe what done looks like before they start, they cannot promise you when it will arrive either.