Is Your Software Supplier Overcharging You?

Check Software Charges Against Delivery

Software supplier overcharging may be your first concern when invoices keep growing but your team still cannot use the system you are funding. You need to understand whether the charges reflect legitimate work, changing requirements, poor delivery or a billing problem.

I would start by connecting what was agreed, what was authorised, what was charged and what was delivered. That gives you a fair basis for challenging costs and deciding what should happen next.

Takeaways

High Costs Need a Clear Explanation

Expensive software development does not automatically mean overcharging. A project can cost more than expected because the original estimate was weak, an integration proves difficult, requirements change or the business takes longer to make decisions.

Some valuable work is also difficult to see. Testing, security improvements, infrastructure changes and investigation may produce little change on a screen.

That does not make every explanation satisfactory. Your supplier should be able to connect material expenditure to an agreed objective, explain what happened and show what the work achieved.

I would separate three questions:

• Billing accuracy: Do the charges match the agreed commercial terms and supporting records?
• Delivery performance: Is the supplier completing work to the expected standard and pace?
• Business value: Is the project still delivering something worth investing in?

These questions can lead to different conclusions. An invoice may be accurate even though the project is poorly managed. A capable supplier may deliver work that your business no longer needs. A billing error may occur within an otherwise productive relationship.

Calling all three problems “overcharging” makes it harder to choose the right response.

Assess Costs Against Working Software

Compare expenditure with evidence of progress, while recognising that working screens are only part of that evidence.

For a customer portal, useful progress might mean customers can complete an agreed process successfully. For an internal finance integration, it might mean transactions move correctly between systems and exceptions can be reconciled.

A demonstration should show the business scenario that matters. Ask the supplier to walk through the complete process, including relevant failure conditions, rather than showing isolated screens.

For example, a wholesale business might need an order to move from customer submission through stock allocation, pricing and accounting. A polished order-entry page demonstrates only part of that outcome.

Ask What Completed Actually Means

“Development complete” can mean different things to different people. The developer may mean the code has been written. Operations may expect testing, documentation and release to be finished.

Agree which state the supplier is reporting:

• Work has started.
• Code has been written.
• Testing has passed.
• The agreed business outcome has been accepted.
• The change is available for operational use.

These distinctions help leadership understand what remains.

Where a supplier uses Scrum, the Scrum Guide describes completed increments as usable and ties completion to agreed quality measures. A team’s delivery language should give you comparable clarity, whether or not it follows Scrum.

Include Less Visible Engineering Work

Ask for evidence appropriate to the activity. A security improvement may be supported by test results and an explanation of the risk addressed. Integration research may produce findings, constraints and a recommended direction.

Investigation does not need to produce a successful feature every time. It should still have a purpose, a reasonable limit and a useful conclusion.

A supplier that explains why an approach will not work may have prevented a larger mistake. Repeated investigation without decisions or revised estimates deserves closer attention.

Reconcile Invoices With Agreed Work

A useful software development invoice review follows a clear chain from the charge back to the agreement and forward to the outcome.

Start with one recent billing period or a disputed milestone. Trying to reconstruct the entire project immediately can overwhelm both teams and delay a practical answer.

Use a simple reconciliation table:

Review item	Evidence to examine	Question to resolve
Contractual basis	Agreement, proposal and relevant terms	What work and charging method were agreed?
Authorised changes	Approved variations and decision records	Who approved additional work and its cost?
Invoice details	Billing period, charges and supporting records	Does the invoice follow the agreed basis?
Delivery records	Work items, releases and test evidence	What activity and outcomes support the charge?
Acceptance status	Agreed criteria and feedback	What is complete, outstanding or disputed?

For time-based work, examine whether the billed activity matches the agreed rates, roles, period and scope. For a fixed-price milestone, focus on the payment trigger and whether the milestone conditions have been met.

Do not assume that a fixed-price supplier must justify its internal margin or disclose every hour worked. Equally, a time-based arrangement does not remove the need to explain activity and progress. The agreement determines the reporting and evidence obligations.

Keep a short exception list. Record the invoice line, amount, reason for concern, evidence requested and supplier response. This is more useful than an email saying the whole project feels too expensive.

Separate New Scope From Rework

Additional charges need to be assessed against the agreed requirements and commercial terms. The label attached to the work does not settle who should pay.

A supplier may describe an item as a change request while your operations team considers it an unfinished requirement. Both views need evidence.

Classify Why Extra Work Is Needed

The following distinctions provide a starting point:

Type of work	Example	What to check
New requirement	Adding another payment method after scope approval	Was it requested, estimated and authorised?
Defect correction	A calculation does not meet an agreed rule	What do acceptance, warranty and defect terms say?
Unresolved requirement	A necessary exception was never clarified	Who held the discovery responsibility and assumptions?
External change	A third-party interface changes during delivery	How does the agreement allocate this risk?
Repeated implementation	A component is rebuilt after an unsuitable design choice	Why was the original approach chosen, and who carries the cost?

Consider a hypothetical distributor that requests multi-warehouse allocation after approving a single-warehouse design. That may be a legitimate expansion.

If the approved design already requires multi-warehouse allocation, charging again simply to deliver it raises a different question.

Neither example establishes a legal entitlement on its own. The contract, recorded assumptions, approvals and actual circumstances matter.

Examine Incomplete Discovery Fairly

Incomplete discovery can create costs without anyone deliberately overbilling.

The supplier may have priced against assumptions that were not tested. The business may have omitted an exception because staff considered it obvious. Both parties may have approved a broad description without agreeing what success looked like.

I would ask when the missing requirement became known, what each party reasonably understood and how the supplier communicated the impact.

The immediate goal is to establish a sound basis for the next decision. Questions about contractual responsibility should go to an appropriately qualified legal adviser.

Review Contract and Change Controls

Read the commercial terms before deciding that a charge is improper. Your expectations may be reasonable, but the agreement is the starting point for understanding the supplier’s obligations.

Australian government guidance on preparing a contract covers matters such as payment, intellectual property, variations and dispute resolution. Use those areas to organise your questions, and seek legal advice where the wording or your rights are unclear.

Different charging models need different controls.

Fixed Price Needs Clear Boundaries

A fixed price can provide useful certainty around an agreed scope. That certainty becomes less useful when deliverables, assumptions, exclusions or acceptance conditions are vague.

Check what the price covers and what triggers a variation. Ask whether a requested change alters the outcome, the delivery method or something already included.

A low initial price followed by repeated variations deserves examination. So does a business repeatedly expanding requirements while expecting the original price to hold.

Time Based Work Needs Visibility

Time-and-materials arrangements can suit uncertain work because priorities and scope can adapt. Their commercial risk is continued expenditure without enough visibility or a useful stopping point.

I would expect leadership to understand the current spending position, completed outcomes, remaining uncertainty and the next funding decision.

Depending on the agreement, useful controls may include an expenditure cap, prior approval above a threshold and a regular forecast. A timesheet alone does not explain whether the project remains a good investment.

Milestones Need Observable Outcomes

Milestone payments work best when the payment trigger is clear.

“Integration complete” leaves room for disagreement. A more useful milestone identifies the systems involved, the transactions covered, relevant testing and the evidence needed for acceptance.

Check how partial completion, defects and dependencies affect the payment trigger. Do not assume that a milestone label proves completion or that every outstanding issue automatically prevents payment.

No charging model removes uncertainty. The practical question is whether the controls match the work and give both parties a shared basis for decisions.

Review Supplier Performance Fairly

Assess the supplier against commitments, constraints and evidence over time. One difficult month or one disputed invoice rarely explains the full relationship.

Useful questions include:

• Are promised outcomes being delivered and accepted?
• Are estimates revised before the budget is exhausted?
• Are defects recurring or being addressed?
• Does the supplier explain blockers and decisions clearly?
• Are business-side delays visible alongside supplier delays?

Technical evidence can help, but it needs interpretation. Source-code history, test results, release records and architecture information can corroborate delivery claims.

Counting code changes or completed tickets is not a reliable substitute for assessing outcomes. A developer can create activity without delivering useful capability. A small change can also resolve a difficult operational problem.

Give the Team a Fair Hearing

People before technology applies to supplier reviews too.

Developers may be dealing with conflicting instructions, unavailable decision-makers, poor source data or a legacy system that was more difficult than expected. Your staff may be carrying the operational cost of unfinished work while receiving explanations they cannot evaluate.

Hear both perspectives. Ask the supplier to respond to specific findings and distinguish explanations supported by evidence from assumptions.

Where the recurring issue is unclear ownership, weak reporting or uncontrolled priorities, Project Delivery consulting may be more relevant than another billing check.

Check Access to Your Business Assets

Check your practical access to the assets needed to operate and maintain the software. Paying invoices should not be your only connection to the system your business depends on.

Depending on the arrangement, examine:

• Source-code repositories and release history.
• Hosting and cloud accounts.
• Domain registrations and essential service accounts.
• Build and deployment instructions.
• Technical documentation and configuration records.
• Backups, data exports and recovery arrangements.

Ownership, licence rights and access are separate questions. Payment does not, by itself, establish what intellectual property rights you hold.

Some suppliers legitimately use their own platforms or licensed components. Understand what your business can access, what it can transfer and what continuing services it requires.

From an operational perspective, I would favour appropriate business-controlled accounts and documented access where the agreement supports that model. Access should be authorised, proportionate and secure.

An invoice dispute should also prompt a continuity check. Identify what would happen if the relationship deteriorated, while avoiding disruptive account changes or removal of access without an agreed plan and suitable advice.

Escalate Concerns With Specific Evidence

Raise the discrepancy clearly and give the supplier an opportunity to explain or correct it. An evidence-based conversation is more productive than an accusation of dishonesty.

A practical escalation sequence is:

1. Identify the charges or outcomes you cannot reconcile.
2. Compare them with the relevant agreement and approvals.
3. Ask for the missing explanation or evidence.
4. Record which points are resolved and which remain disputed.
5. Follow the agreed escalation process for unresolved issues.

For example, a hypothetical CFO could write: “We cannot reconcile these three charges with the approved changes and release record. Please provide the supporting approvals and explain their delivery status.”

That gives the supplier a defined question to answer.

Australian government guidance on preventing and resolving business disputes recommends reviewing the circumstances, communicating and considering appropriate assistance when a dispute cannot be resolved directly.

Get qualified legal advice about disputed payment obligations, deadlines, withholding payment or termination. An independent technical assessment can help establish delivery facts, but it does not determine your legal rights.

When an Independent Review Helps

Independent review is useful when the uncertainty is commercially important and your business cannot resolve it confidently from its existing evidence.

Internal action may be enough when the issue is a duplicate invoice, an incorrect rate or a missing approval that both parties can identify and correct. A clear reconciliation and written agreement may resolve the problem.

Independent assessment becomes more useful when commercial and technical explanations conflict. You may need to understand whether repeated rework is justified, whether claimed progress is usable or whether technical constraints explain the cost.

I would define the decision before defining the review. “Help us determine whether these charges are supported” is more useful than “tell us everything wrong with the supplier”.

The assessment should distinguish supported findings, reasonable explanations, missing evidence and matters requiring legal advice. Its value is a clearer decision, including where the evidence supports continuing with the existing supplier.

Recognise Recurring Leadership Gaps

If every invoice becomes a dispute, the business may need stronger ongoing oversight.

Someone needs to connect priorities, delivery commitments, expenditure, risk and executive decisions. Finance can check arithmetic without being equipped to assess technical progress. Developers can explain implementation without holding authority over business priorities.

Where that gap persists, Fractional CTO support may be appropriate. It is a separate leadership decision, rather than an automatic consequence of commissioning a review.

Frequently Asked Questions

Is a Large Invoice Overcharging?

A large invoice alone does not establish software supplier overcharging. Check the agreed charging basis, authorised work, supporting records and delivery status before drawing that conclusion.

Should We Pay to Fix Software Bugs?

Responsibility for defect correction depends on the agreement, acceptance criteria and circumstances. Distinguish a failure to meet an agreed requirement from a new requirement or external change, and obtain legal advice if responsibility remains disputed.

What Evidence Should We Gather First?

Start with the agreement, recent invoices, approved changes, delivery reports and acceptance records. Add technical evidence where it helps answer a specific question rather than requesting every available project document.

Should We Stop Paying the Supplier?

Do not assume that uncertainty about progress gives you a right to withhold payment. Check the dispute procedure and obtain qualified legal advice about payment obligations and deadlines.

Can We Review Our Current Supplier?

Yes. An independent review can clarify delivery and cost concerns while leaving the existing relationship in place. The evidence may support billing corrections, clearer controls or a delivery reset rather than a supplier change.

Get Clarity Before Committing More

You need a defensible explanation of what your business is paying for and what it is receiving. If those facts remain unclear, request an independent Software Development Review and explain the expenditure, delivery concerns and decision you face. Establish the evidence before deciding whether your software supplier is overcharging.