IT services invoices often combine retainers, projects, approved time, milestones and usage. The arithmetic may be simple while the source trail is not. A useful preflight checks whether every charge belongs to the customer, period and legal entity shown on the invoice.
The goal is not a longer checklist for its own sake. It is a repeatable stop point before sending, when finance can still correct the record without creating a customer dispute or a reconciliation problem.
Check scope and billing trigger
First confirm what authorises each charge. A statement of work may permit monthly time, accepted milestones or a fixed retainer. Project progress alone is not a billing trigger unless the agreement says it is.
Second, verify that the service period and customer are unambiguous. Work performed for one business unit should not drift onto another entity's invoice because the teams share a project name.
Check approved inputs and rates
Third, distinguish recorded work from approved billable work. Time can be operationally valid while still being internal, excluded or waiting for client approval.
Fourth, retain the rate source. A line should point to the applicable contract, rate card or approved exception, including the period and currency in which that rate applies.
Check entity, currency and review
Fifth, make the issuing entity explicit. Its legal identity, tax position, bank details and document sequence should remain coherent rather than being copied from a previous invoice.
Sixth, preserve currency context. The invoice currency, source currency and any conversion policy are different facts. Seventh, route the completed record to the accountable reviewer before it reaches the customer.
Keep the ledger hand-off narrow
Billing prepares and controls the outgoing invoice. The accounting system remains responsible for the ledger. Send the supported output and identifiers needed for posting without implying that the billing workflow replaces accounting policy.
After sending, retain delivery state, payment references, disputes and adjustments against the original record. A corrected invoice should be traceable to what changed and why.
Error 1: the charge has no explicit commercial trigger
An IT services project may show progress, closed tickets or completed engineering work without yet creating a billable event. Confirm whether the agreement charges a retainer, accepted milestone, approved time period, delivered licence, recurring service or customer quantity. Name that trigger on the proposed line. A project status or internal completion label is evidence only when the agreement gives it that meaning.
If the trigger is missing, stop the line before review. Assign the commercial or delivery owner to provide the agreement reference and evidence. Do not ask finance to infer the rule from prior invoices, and do not allow one apparently correct total to make an unsupported component invisible.
Error 2: recorded work is treated as approved billable work
Time, expenses and service records can be valid operational data while remaining excluded, disputed or awaiting approval. Separate recorded, submitted and approved-for-billing states. The approval should identify the client, project, period and accountable authority. For imported records, retain the source identifier so a reviewer can distinguish a late entry from a duplicate.
When work is excluded, keep the original record and reason. Deleting it damages project evidence and makes utilisation analysis unreliable. When approval arrives after the cut-off, apply the documented late-entry rule rather than quietly inserting the charge into a reviewed invoice.
Error 3: the rate has lost its source or effective date
IT services commonly use role rates, blended rates, retainers, fixed fees and approved exceptions. Resolve the applicable rate from the customer agreement, statement of work, rate card or authorised change. Record the currency and effective dates. A person's default cost or internal rate is not automatically the customer rate.
If a reviewer changes the rate, preserve the prior value and capture the reason and authority. This prevents a one-off concession from becoming an accidental precedent and lets finance reproduce historical invoices after the standard rate changes.
Error 4: the issuing entity is copied from the last invoice
Select the issuing entity from the agreement and approved operating rules. A shared customer or project name does not mean every group company can issue the invoice. The entity determines legal identity, payment instructions, document sequence and the context passed to accounting and tax review.
Require explicit review when the entity changes after preparation. Check that the customer, bank details, invoice numbering context and commercial owner still agree. Group visibility can consolidate operating status, but it must not collapse separate legal identities into one invoice record.
Error 5: currency roles are collapsed
Keep agreement currency, invoice currency, source currency and settlement currency as distinct facts. An approved expense may originate in one currency while the customer invoice is issued in another. Retain the permitted conversion source, date or period, rounding rule and authority for exceptions rather than storing only the converted amount.
Do not rewrite the issued invoice when payment settles in another currency or the ledger records a reporting-currency equivalent. Match through stable identifiers and let the authorised accounting process handle exchange differences, fees and ledger treatment.
Error 6: recurring and variable components are flattened
A managed-service invoice can combine a monthly platform or support fee with approved engineering time, usage quantities or a milestone. Presenting one customer-facing document can be sensible, but each component needs its own period, source and rule. A recurring label must not conceal a changed scope or a variable charge that has not passed cut-off and review.
Show the fixed schedule version, the approved variable set and any exception separately during review. This makes the total easier to explain and prevents a correction to one component from forcing finance to reconstruct the whole invoice.
Error 7: review happens before the invoice is assembled
Approving isolated time sheets or project records is not the same as approving the outgoing invoice. Assemble the customer, entity, periods, lines, discounts, currency, payment terms and required identifiers first. Then route the complete version to the accountable reviewer so interactions between components are visible.
If the invoice changes after approval, identify the affected lines and reopen the necessary decision. Preserve the approved version, changed version, reason and timestamps. A final file overwritten in place cannot show whether the customer received what the reviewer actually approved.
Run the IT invoice preflight in one controlled sequence
Start with identity and scope, then verify trigger, approved source, period, rate, entity and currency. Assemble the invoice, inspect changes, complete outgoing approval and retain the identifiers required for delivery and accounting hand-off. Give every failure a state and owner. A checklist that only says pass or fail does not help the team resolve the record.
Use a representative invoice containing fixed and variable components. A second person should reproduce each line without opening unrelated chats. Where they cannot, record the missing source or decision and repair that hand-off. The goal is not maximum documentation. It is the minimum complete evidence needed for a defensible customer invoice.
Keep post-send corrections and collections connected
After sending, record delivery, customer questions, dispute ownership, reminders, receipts and remaining balance against the issued invoice. A technical dispute about service scope must return to the appropriate delivery or commercial owner without removing finance's view of the receivable and next action.
When correction is required, follow the approved document and accounting process. Link the correction to the original invoice and explain what changed. Billing maintains the operating record; accounting remains authoritative for ledger treatment and statutory reporting.
Decision summary
Keep the commercial trigger and source evidence visible for every material charge.
Separate preparation, review, correction, sending and accounting responsibilities.
Retain versions, reasons, owners and timestamps whenever a decision changes.
Test the control with one difficult invoice another authorised person can reproduce.
A worked mixed-service invoice
Consider an invoice with a monthly managed-support fee, an accepted implementation milestone and approved engineering time. The support fee comes from the current recurring schedule and service period. The milestone comes from the agreement and named acceptance evidence. The time line comes from a closed set of approved entries and the applicable client rate. These sources can share one invoice, but each must survive as a separate inspectable calculation.
Before review, finance confirms the customer and issuing entity, checks that all three components use the same invoice currency or an authorised conversion policy, and verifies that the customer reference and payment terms apply to this version. The outgoing reviewer sees what changed from the prior period. After sending, the delivery state and accounting identifier stay attached so a receipt or dispute can be matched without rebuilding the case.
Preflight ownership and stop conditions
Assign each check to the role that controls the fact. Delivery or commercial owners confirm scope and acceptance. Project or service owners confirm operational source records. Finance confirms invoice assembly, entity, currency and outgoing review. The authorised accounting and tax processes confirm ledger and jurisdiction-specific treatment. One person may hold several roles in a small team, but the decision boundaries should remain clear.
Define a stop condition for every failure. Missing acceptance holds the affected milestone. Unapproved time remains outside the invoice set. An unknown rate returns to the commercial owner. An entity mismatch reopens invoice identity review. A currency exception requires its permitted rate basis. A post-approval edit creates a new reviewable version. Explicit stop conditions turn the preflight from a passive checklist into an operating control.
Evidence to retain after the check
Keep the agreement reference, source identifiers, approved quantity, rate source, entity, currency context, reviewer decision, invoice version and delivery state. The evidence should be sufficient for another authorised person to reproduce the invoice without preserving unrelated personal or operational data. Apply the organisation's approved retention, privacy and access rules rather than collecting documents indefinitely.
Review the preflight after corrections and disputes. If customers repeatedly question the same description, source or period, improve the invoice explanation and upstream hand-off. If most delays come from one exception type, repair that rule or ownership path. Do not remove a genuine authority check solely to reduce cycle time. The objective is fewer preventable errors with decisions that remain defensible.
Compact preflight record
For every failed check, retain four facts: the affected invoice line, the evidence or decision that is missing, the person responsible for resolving it and the next review state. Add the expected action date when delay matters. This small record makes the queue operable and gives the next reviewer enough context to continue without repeating the investigation.
Close the failure only when the required evidence is attached or the affected charge is removed through an authorised decision. A comment saying resolved is not enough. The final invoice version should show that every included component passed its applicable trigger, source, rate, entity, currency and outgoing-review controls.
Record the check against the exact invoice version that will be sent. If preparation changes the customer, period, line amount, entity, currency, payment instruction or supporting reference afterwards, reopen the affected control. This prevents an earlier approval from being incorrectly applied to a materially different customer document.
Version checkpoint
Record the completed preflight against the exact invoice version that will be sent. If preparation later changes the customer, period, line amount, entity, currency, payment instruction or supporting reference, reopen the affected control. An approval for an earlier draft must not be applied silently to a materially different customer document.
Put the control into practice
Run the seven checks against one mixed invoice: scope, trigger, approved input, rate, entity, currency and review. If the team cannot reproduce the amount from those facts, the invoice is not ready to send.
Run the review on a real case
An IT services invoice combines a monthly support fee, approved engineering time and usage from a customer environment. Before sending, trace each line to its agreement, period and rate source. A correct total is not enough when one input belongs to another entity or has not cleared review.
Run the preflight on the assembled invoice, not on isolated source exports. The reviewer should see customer identity, issuing entity, service period, currency, rate evidence, approval state and the accounting identifier that will survive the hand-off.
Case-review checklist
Scope and billing trigger agree
Time and usage periods are closed
Rate and currency sources are retained
Issuing entity matches the agreement
Outgoing approval is complete
The checklist does not certify tax treatment or replace accounting review. Jurisdiction-specific fields, ledger posting and revenue recognition remain with the authorised tax and accounting processes.
Continue in context