What to verify before the next invoice

Before you pay the next invoice on a SaaS build, three things have to be true in your hands. The commits that invoice covers are in a repository you can open. The acceptance sentence for this period passes or fails when you run it, without the vendor driving the mouse. A second account cannot read the first account's record. If any of the three is still a promise, a screen share, or a sentence in Slack, the invoice is early. Pay the lines you could perform. Hold the line you could not.

This is the payment, not the status meeting and not the signature. A weekly update tells you what got harder and what is left. The contract tells you who owns the copyright and where the repository was supposed to live from the first commit. Neither one is a receipt. A receipt is a claim that a specific period of work now exists as something you can touch. The rest of this article is how to touch it in an afternoon, and what to do when one of the three checks fails.

None of what follows is legal advice, and it is not a reason to invent a dispute. Copyright, setoff, and whether you may withhold a line are questions for the draft you signed and for a lawyer who has read it. The checks below are how you learn which lines describe work that is actually there.

The commits for this period are in your account. NIST's Secure Software Development Framework, SP 800-218 version 1.1, states task PS.1.1 as: "Store all forms of code — including source code, executable code, and configuration-as-code — based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access" (NIST, SP 800-218, February 2022). Read that as a founder, not as a security programme. "Your account" means the organisation named on the host is yours, the vendor is a member you invited, and the history for the dates on the invoice is visible when you are alone. A zip file emailed on invoice day is a snapshot. It has no record of who changed what, and it cannot be compared with last month's zip except by someone willing to diff two archives by hand.

Open the log and filter it to the invoice dates. You are not judging whether the code is good. You are confirming the period exists. A log that is empty across those dates, or that lives in an organisation you do not administer, means the invoice is describing work you cannot see. That is the same failure the handover is written to prevent at the end, and the same failure the questions before you sign are written to prevent at the start. The invoice is the only moment in the middle when you have leverage that is not a mood. Use it to look, not to relitigate the whole contract.

You run the acceptance sentence yourself. One workflow, one kind of user, one sentence that is false if the workflow does not work: a clinic can check eligibility for one patient and see a yes or a no. The vendor's continuous-integration badge is evidence that the vendor's tests passed on the vendor's machine. It is not evidence that the sentence is true on the build you are being asked to pay for. SP 800-218 task PW.8.2 tells a producer to scope the testing, design the tests, perform the testing, and document the results, including recording what was found in the team's issue tracker (same publication). You are the acquirer. For this one sentence, you are also the person who performs it. Sit down without a call. Use an account that is not the vendor's demo login. Follow the sentence. Write down the first step where it becomes false, or write down that it held.

If you cannot do that because nobody ever wrote the sentence, you do not have an invoice problem. You have a scope that was never cut to something a person can fail. That work is how to scope an MVP so it ships, and it belongs before the next period starts, not inside a payment argument. Do not let a vendor fold "we'll know it when we see it" into a line item called acceptance.

A second account is refused. Sign in as the least-privileged user you can create, copy a request the first account was allowed to make, and send it with the second session. If the response contains the first account's record, you are being asked to pay for a hole. The OWASP Top 10 for 2021, in the prose above the A01 table, says that 94% of applications were tested for some form of broken access control, with an average incidence rate of 3.81% (OWASP, A01:2021 – Broken Access Control). Read the two numbers as different facts. Tested is not vulnerable. The 94% is how often this class of weakness was looked for. The 3.81% is the average incidence rate in the contributed data, not a prediction about your build. The table's maximum-coverage cell is 94.55%, which is not the same figure as the rounded 94% in the sentence. What you take from the page is the practice, not a rate to quote at your vendor: this is the weakness serious programmes already test for, and the test is short enough to run before you pay.

The interface hiding a button is not the test. The request behind the button is the test. A generated screen makes the visible thing easy to ship and the check easy to skip, which is why the same two-minute replay shows up when an AI-built prototype meets real users. Run it on the build this invoice names. A pass last quarter is not a pass on the code that landed on Tuesday.

The lines match a written list. A low number with a silent exclusion is a change-order schedule. At payment, the job is narrower than the original comparison of quotes: each line on this invoice points at a commit range you opened, or at the acceptance sentence you ran, or at a written exclusion you already agreed. A Slack thread that felt like agreement is not a line. If a line says "discovery" or "support" and neither word is defined in the period, ask which commits it names before you pay it. The exercise of comparing two very different proposals is its own article, and it should already be behind you. Do not reopen it. Do not ignore a line that names no artefact either.

Where customer data sits is part of the same afternoon, because an invoice that quietly extends "the vendor's cloud, for convenience" is buying another month of a copy you do not control. Which region, which account, who besides you can read a production row, and whether that convenience has an end date are the questions your first security questionnaire will ask in the customer's words. You do not need the spreadsheet yet. You need the honest answer to exist before you pay for another period of the arrangement.

When one check fails, split the invoice. Pay the lines whose commits you opened and whose sentence you ran. Hold the line that failed, and write the failure in one sentence the vendor can reproduce: the log for 1–15 October is not in the organisation we administer; the eligibility sentence fails at the payer step; the second account received the first account's record. A hold on the entire invoice, including the lines you verified, turns a specific miss into a relationship fight, and it teaches the next update to be vaguer. A hold on nothing, because the call was friendly, teaches the next invoice that the three checks are optional. Neither lesson is the one you want.

There is a version of this afternoon where hiring more engineering is the wrong purchase. You do not yet have one workflow and one user, so there is no sentence to run — name it before you buy another month. Nothing has been built, and the argument is about the paper you have not signed — that is the signature meeting, not a payment audit. You are still choosing between two firms — run the criteria, and do not use an invoice from the first firm as a substitute for the second firm's repository. A product that already has a customer, and that customer has already seen another customer's data, is not an invoice problem either. That is an incident, and it has its own first hour.

What the three checks look like when a product actually has more than one kind of user is ordinary and visible. Gigbase, a multi-tenant workspace for agencies, had to put subscription plans, role-based access for agencies, admins, and team members, and invoice management in one product, because the bill and the permission model constrain each other. A founder verifying a period can log in as two of those roles and can open the invoice module as themselves. Nothing in that description is a headcount or a duration. The shape is the point: if the period claims that roles and billing exist, you can see both without anyone narrating them.

On the day the invoice arrives, do the three checks before the call. Open the log for the dates. Run the sentence alone. Replay one request as the other account. Then pay what you could perform. A startup software development company that expects this will send the link to the log with the invoice, because the check takes them nothing they were not already doing. One that needs the call in order for you to see the work is telling you where the history lives. If the period is a fixed slice of an existing product rather than an open retainer, an AI integration sprint is the shape where an acceptance sentence and a date range are both written down before the first week, which is what makes the afternoon possible. The criteria for choosing who sends you that invoice sit on the page written for a top saas development company. That page is criteria, and it does not rank anyone, including us.