What data does your ERP hold on IT/pro services?

Executive Summary

An ERP is a payment system, not a contract system. It records that an invoice matched a purchase order and that the purchase order was approved, then releases payment. None of that tests whether the rate charged matches the rate in the master service agreement, whether the hours billed fall inside the statement of work's scope, or whether a milestone was actually delivered before its payment triggered.

The documents that would answer those questions, the SOW, the rate card, the change order log, live outside the ERP as PDFs in a contract repository, an email thread, or a shared drive. Three-way matching checks the invoice against the PO and the receipt; it does not open the SOW to check the rate or the scope boundary.

What changes this is treating the ERP's data as a starting index, not an answer. Every invoice it holds points to a contract it does not hold, and that contract is where the audit actually happens.

1. What invoice-level fields does the ERP actually store?

The ERP stores the vendor name, invoice number, invoice date, PO number, line amount, GL account, and payment status for each IT or professional services bill. Some systems capture a free-text description field and a cost center. None of these fields record the labor rate that was contracted, the scope boundary of the work, or the milestone the payment was tied to, so the stored data confirms an invoice was paid, not that it was priced or scoped correctly.

A typical accounts payable record for a professional services invoice carries perhaps a dozen fields, and all of them describe the transaction, not the agreement behind it. Vendor, amount, date, approver, GL code: this is enough to close the books.

What is missing is any field for the day rate the SOW specifies, the total hours the scope allows, or the deliverable that was supposed to trigger payment. The ERP was built to move money, not to interpret contracts, so it was never designed to hold that data.

This matters because the invoice line item, on its own, looks reasonable. A consultant billed at an hourly rate for a block of hours reads as ordinary. Whether that rate is the contracted rate, and whether the hours sit inside the SOW's cap, is a question the ERP has no field to answer.

2. Where do the contract terms actually live?

The master service agreement, the statement of work, the rate card, and any change orders typically live as PDFs in a contract management tool, a shared drive folder, or an email attachment, separate from the ERP entirely. Nothing links the invoice record to the specific clause it should satisfy, so validating an invoice against its contract means manually pulling both documents and comparing them line by line.

A rate card sits in one document, a statement of work in another, and a change order authorizing a scope addition in a third, often approved over email with no update to the original SOW. None of these carry a system link back to the PO number the ERP uses to track payment.

That separation is structural, not accidental. Contract negotiation and invoice payment are handled by different teams on different timelines, and the systems that support each function were never built to talk to each other.

A. What a change order changes

A change order can add hours, extend a deadline, or introduce a new rate for a new phase of work. Once signed, it should supersede the original SOW's terms for that scope. If the change order is filed by email and the SOW is filed in a contract repository, an invoice matched against the original SOW alone will look wrong when it is actually correct, or right when it is actually wrong.

3. Can three-way matching catch a rate or scope violation?

Three-way matching checks that the invoice quantity and amount agree with the purchase order and the receipt of goods or services. It confirms the numbers reconcile internally. It does not check the PO's unit rate against the SOW's contracted rate, and it does not test whether the hours or deliverable billed fall inside the statement of work's defined scope, because that comparison requires a document the match never opens.

Three-way matching was built for goods receiving: does the invoice quantity match what arrived, and does the price match the PO. Applied to professional services, it answers a narrower question than it appears to: does the invoice agree with the PO that was cut for it.

If the PO itself was cut at the wrong rate, or if the PO's scope was never updated after a change order, three-way matching will pass an invoice that is wrong at the source. The control validates internal consistency between two ERP-native documents, not consistency with the underlying agreement.

4. What does a professional services invoice actually itemize?

A professional services invoice typically lists a consultant name or role, hours worked in a period, a billing rate, expenses if applicable, and a total. It rarely cites the SOW section or milestone it corresponds to. That omission makes the invoice harder to trace back to the specific scope clause or rate schedule the buyer agreed to, and the ERP's own record does nothing to close that gap.

The line items look precise. Hours logged at a named rate for a named consultant reads as an auditable record. But precision at the line-item level is not the same as traceability to the contract.

An invoice that does not reference a SOW section number or milestone forces the reviewer to reconstruct that link manually, matching a role description to a rate card entry and a date range to a phase of work.

• Consultant or role: Named individual or generic title standing in for a specific rate card tier.
• Billing period: Date range the hours or fixed fee cover, rarely tied to a milestone date.
• Rate and hours: The figure the ERP stores as the line amount, unchecked against the SOW's rate table.
• Expenses: Travel or materials billed separately, often outside the SOW's cap entirely.

5. Why does software spend need a different kind of check?

Software license and subscription invoices carry a different drift pattern than time-and-materials professional services: the exposure sits in the annual renewal or true-up, not the individual invoice. The ERP records each payment as a separate transaction and has no field for the license count the contract entitles, so a renewal invoice can restate an old count without anyone comparing it to actual usage.

A monthly subscription invoice looks routine because it matches the prior month's invoice. That consistency is exactly what hides the problem: if the original license count was wrong, or usage has dropped, the invoice keeps repeating the same error every cycle.

The contract document that would catch this, the license agreement and its usage terms, is the same kind of external PDF that a statement of work is. The ERP has no more visibility into it than it does into a professional services SOW.

6. What would it take to close the gap between the ERP and the contract?

Closing the gap means treating every ERP invoice record as an index entry pointing to a contract document, then pulling both together for comparison: PO to SOW, rate line to rate card, hours billed to scope cap. This is manual reconciliation work when done invoice by invoice, and it is the specific work a margin drift diagnostic performs across a full population of past invoices in one engagement.

The reconciliation itself is not complicated in principle. Pull the invoice, pull the SOW or rate card it should match, and compare a small number of fields: rate, hours or units, scope boundary, milestone trigger.

What makes it hard is volume and document fragmentation. A single vendor relationship can span dozens of invoices, several change orders, and one master agreement, each stored separately, and the comparison has to happen for every invoice, not a sample.

A diagnostic engagement does this reconciliation across 12 to 18 months of historical spend, across ValueXPA diagnostics, because that is the window where unclaimed credits and rate errors remain recoverable. It applies the same fields described above at a volume a manual review rarely reaches.

Where each data element lives, ERP or contract document.

For the wider pattern this sits inside, start with the margin drift guide.

7. Frequently Asked Questions (People Also Ask)

Does the ERP store the statement of work for a professional services vendor?

No. The ERP stores the invoice and the purchase order it was matched against. The statement of work, the document defining scope and deliverables, is typically filed separately as a PDF in a contract repository or shared drive, with no system link back to the PO.

Can I add a field to the ERP to track the contracted rate?

Some ERPs allow custom fields, but adding one does not populate it automatically. Someone still has to read the rate card and enter the value, then keep it current as change orders are signed. The gap is a process gap, not just a missing field.

Why doesn't three-way matching catch a rate that's higher than contracted?

Three-way matching compares the invoice to the purchase order and the receipt, all ERP-native documents. It never opens the rate card or the SOW, so if the PO itself was cut at the wrong rate, the match will pass an invoice that is wrong from the start.

What is the difference between a rate card and a master service agreement?

A master service agreement sets the overall terms of the vendor relationship: liability, term, termination. A rate card lists the specific hourly or day rates for each role or tier under that agreement. Both typically live outside the ERP as separate documents.

How do change orders affect what the ERP shows for a project?

A change order can revise hours, rates, or deadlines for a scope already under a signed SOW. If it is approved by email rather than filed with the original SOW, the ERP's PO record keeps referencing the pre-change terms, and an invoice reflecting the new terms will look like a mismatch.

Is software subscription spend audited the same way as consulting invoices?

The document trail is similar, both rely on an external contract the ERP doesn't hold, but the drift pattern differs. Consulting drift shows up per invoice in rate or hours. Software drift accumulates at renewal, when a license count or usage figure goes unchecked against the agreement.

What should an AP team pull before approving a large professional services invoice?

The invoice, the relevant SOW section or milestone description, the rate card entry for the billed role, and any change order signed since the SOW was executed. Comparing these against the invoice line items is what the ERP's own approval workflow does not do.

Does a margin drift diagnostic replace the ERP or the contract repository?

No. It uses both as inputs. The diagnostic pulls invoice records from the ERP and contract terms from wherever they are filed, then reconciles the two, work that would otherwise be done manually and inconsistently across vendors.