Auditing the Code Your Vendor Delivered Before You Pay the Final Invoice

The project is done, or so the agency says. The final milestone is marked complete, the invite to sign off has landed in your inbox, and the final invoice is sitting a few days behind it. This is the one point in the relationship where you still have leverage. Once you sign the acceptance and pay, most of that leverage is gone. The sensible move is to audit the code before final payment, with a few hours of your own time or a few days of outside help, checking what your vendor actually delivered rather than what the proposal described.

You do not need to read a line of code to do the first pass yourself. You do need to know what to ask for and what a missing answer usually means.

How to audit code before final payment, without reading a line of it

Four questions separate a clean handover from a problem you will not discover for months.

Does the project build from the repository you were handed, on a machine that has never touched it before? Ask the vendor to prove it. A clean clone, a documented setup step, and a running application on a fresh machine is the baseline. If the only working copy lives on a laptop or a server nobody but the vendor can access, you have not actually received the software. You have received a demo of it.

Are the accounts in your company's name? Domain registrar, hosting provider, source control organization, any paid API keys, the email account used to register them. It is common, and not malicious on its own, for a freelancer or agency to spin these up quickly under their own account during development. It becomes a problem the day the relationship ends and you discover the hosting bill, the domain, or the repository itself belongs to someone who no longer answers your emails.

Is there any test coverage at all, and does it run? You are not checking for perfection. You are checking for evidence that someone other than the original author could change this code without breaking something silently. A project with zero tests is not automatically broken, but it is a project where every future change is a guess.

Is the documentation enough for a different developer to start work next week? A short setup guide, a note on where the main logic lives, and a list of the third-party services and licenses in use. If the answer to "what happens if this developer disappears" is "we would have to start reading the whole codebase cold," that is a cost you are agreeing to pay the moment you sign off.

None of these four checks require you to understand a single function. They require the vendor to produce specific, verifiable things, and they tell you a great deal from how quickly and completely those things show up.

What a short outside audit covers that you cannot check alone

The four checks above catch the obvious gaps. They will not tell you whether the code underneath is secure, whether it will hold up as usage grows, or whether what looks like a working feature is actually one bug away from a serious failure. For that, a focused external review over three to five days is usually enough, and it does not require weeks of access or a full line by line read of everything that was built.

A review at this stage typically looks at how the application handles authentication and access control, whether user input is handled safely, how the data layer is structured and whether it will hold up under real load, and whether the dependencies in use are current and free of known vulnerabilities. It also checks for the kind of shortcuts that are invisible in a demo: hardcoded credentials, missing error handling, logic copied and pasted across files instead of shared properly, and features that work for the one test case the vendor walked you through but fail on anything slightly different.

We have described this kind of review in more detail, including how a structured code audit methodology works end to end, and what a professional code review typically costs in Germany and what you get for that spend. The short version for the acceptance stage: a few days from an independent code quality review usually costs less than the cleanup you would otherwise pay for after the fact, and it costs far less than discovering the problem after the vendor has already cashed the final invoice.

Abnahme and the Mängelrüge lever, in plain terms

If your contract is governed by German law and structured as a Werkvertrag, the moment you accept the work, known in German as the Abnahme, matters legally, not just practically. Once you sign the acceptance, the burden tends to shift: proving a defect existed before signing becomes harder, and the window to raise it under a Mängelrüge, a formal notice of defects, starts running. This is exactly why the audit belongs before the signature, not after.

This is not legal advice, and the details of your specific contract, the defects you find, and how your acceptance clause is written will change what options you actually have. If an audit turns up something serious, the right next step is a conversation with a lawyer who can tell you what that finding means for your Abnahme and your remaining rights under the contract, before you sign anything or release the final payment.

Getting findings into the acceptance protocol

Whatever the audit turns up, informal feedback in a call or a chat message is not the same as a documented finding. Put every issue in writing, attached to the acceptance protocol itself if your contract has one, with enough specifics that nobody can later claim they were unaware: what was found, where, and what a fix would need to look like. If the vendor fixes something before you sign, note that too, with a date.

This record is what makes the Mängelrüge window meaningful later, and it is what turns "we were not happy with the handover" into something you can actually act on. A vague conversation that both sides remember differently six months later protects nobody. A written list attached to a signed document protects you.

When this is worth bringing someone in for

If your project is small, low-risk, and the four checks above come back clean, you may not need an outside reviewer at all. The calculus changes once real money, customer data, or your ability to hire a different developer later are on the line. The same logic applies after the handover too: if you want an ongoing read on whether a team's work is holding up without reading code yourself, the signals to watch month over month are different from the one-time acceptance check described here, but they come from the same place, trusting evidence over assurances.

If you are a few days from signing off on a vendor's final deliverable and want a second set of eyes before the money moves, get in touch at hello@wolf-tech.io or see what we do at wolf-tech.io. A short independent review before you pay the final invoice is far cheaper than finding out what was missing after you already have.