The services GRN problem and the digital receipt

Executive Summary

A goods receipt confirms a quantity arrived. A service has no quantity to count, so the services GRN that AP teams create to force three-way matching to work is a workaround, not a control. It gets built by someone typing a number that approximates a percentage of a contract completed, and that number is not independently verifiable against anything a vendor invoice can be checked against.

The mechanism is straightforward: procurement raises a PO, the vendor delivers hours, a site, or a project milestone, and AP needs a receipt record before the ERP releases payment. Because the ERP's match logic expects a receipt quantity, someone enters one, and that entry becomes the de facto approval regardless of whether the work matches the contract's rate, scope or milestone terms. The control point moves from "does this match the contract" to "did someone click approve."

What changes it is separating receipt from validation. A digital service receipt that captures what was actually delivered, against a structured reference (a rate card, a statement of work, a milestone schedule) closes the gap the manual GRN leaves open. This does not require new software to be claimed; it requires the underlying contract terms to be structured data before the invoice arrives, which is exactly what a margin drift diagnostic produces as its output.

1. Why doesn't a goods receipt process work for services?

A goods receipt confirms a countable event: a pallet arrived, a quantity matches a packing slip. A service has no equivalent physical event to count. Hours worked, a milestone reached, or a site visit completed are all judgment calls, not counts, so the ERP's three-way match logic, built around quantity and unit price, has nothing objective to attach to a service line.

The receipt becomes a placeholder entered to unblock payment rather than a record of what was verified.

Three-way matching was designed for physical goods: purchase order, receipt, invoice, each carrying a quantity and a unit price that can be checked against the other two. A service line breaks this from the start because there is no delivery dock, no packing slip and no quantity that arrives in a truck.

When a services module is bolted onto this workflow, the receipt field still needs a number. AP or the requesting manager types one in, usually a percentage of contract value or a count of hours reported by the vendor itself. That number satisfies the ERP's match requirement without independently confirming anything.

The structural gap this leaves is the same one that shows up when the three-way match gap is examined for goods: a system built to check quantity and price has no field for a rate card tier, a not-to-exceed cap or a milestone definition. Services amplify the gap because the receipt itself is unverifiable by design, not just the match against it.

2. Who actually enters the receipt quantity, and what do they check?

The person entering a services GRN is usually the requesting manager or a delegate in the business unit, not AP and not procurement. They check whether the vendor showed up and did something resembling the scope, not whether the invoiced rate matches the contract's rate card, whether a volume tier applies, or whether a not-to-exceed cap has been reached. The receipt confirms presence.

It does not confirm price.

A requesting manager approving a services GRN is answering one question: did this vendor do the work I asked for. That is a legitimate question and the manager is the right person to answer it. It is not the same question as whether the invoice matches what the contract says the work should cost.

The manager typically has no visibility into the underlying contract's rate schedule, its volume tier triggers, or its NTE cap. Those documents sit with procurement or legal, often as PDFs never loaded into the ERP. The person closest to the work is structurally the person least equipped to catch a rate or term violation.

This split of responsibility is not a training problem. It is a design problem: the receipt step was built to confirm delivery, and confirming delivery and confirming contract compliance require different reference documents and different reviewers. A digital service receipt that pulls the contract terms into the same screen as the delivery confirmation closes that split instead of asking one person to do both jobs from memory.

3. What does a services GRN actually verify, and what does it miss?

A services GRN verifies that someone with knowledge of the engagement approved payment. It does not verify the invoiced rate against a rate card, check a volume tier threshold, confirm a surcharge's expiration date, or catch a milestone billed before it was reached. The receipt and the invoice can match each other perfectly while both diverge from the contract, because neither document is being checked against contract terms at any point in the workflow.

A vendor master file, a rate card and a statement of work each live in different places, and a services GRN references none of them directly. It references the PO line and, sometimes, a loose description of scope. That is enough to confirm someone thinks the work happened.

What it cannot do is answer questions with a contractual answer: is this the hourly rate the contract specifies for this labor category, has this vendor already crossed the volume tier that should trigger a lower rate, does a surcharge on this invoice have an expiration date that has already passed. None of those questions have any field in a standard receipt workflow.

A. Rate verification Rate verification requires comparing the invoiced unit rate to a structured rate card at the labor category or SKU level. A services GRN carries no rate field to compare against, so a rate that has drifted from the contract passes through undetected as long as the receipt itself was approved.

B. Milestone and NTE tracking Milestone-based contracts define a payment schedule tied to deliverables. A GRN approval confirms a milestone happened; it does not track cumulative billing against a not-to-exceed cap across the life of the engagement, which requires a running total the receipt process was never built to hold.

4. What would a digital service receipt need to capture that a GRN doesn't?

A digital service receipt for margin drift purposes needs three things a services GRN lacks: a structured reference to the contract term governing the line, being a rate card entry, a milestone definition, or an NTE cap; a comparison of the invoiced amount against that reference at the moment of receipt; and a record of the variance, if any, rather than a silent pass. Without all three, the receipt still confirms presence and not price.

The first requirement is structure. A contract term stored as a PDF clause cannot be checked automatically by anything, receipt process included. It has to exist as a rate, a threshold or a date before an invoice arrives for it to be checkable at receipt time.

The second requirement is timing. Checking the invoiced rate against the contract after payment has already cleared is an audit, not a control. A receipt that captures the comparison before approval is what actually prevents the drift rather than documenting it after the fact.

The third requirement is a variance record. A receipt that either matches or gets manually overridden with no note of why loses the information a controller needs to see the pattern across vendors. A record that shows what the contract said, what the invoice charged and who accepted the difference turns each receipt into an auditable event rather than a checkbox.

This is a design specification, not a claim about any particular tool's current capability. Building it requires the contract terms to exist as structured data first, which is the output a margin drift diagnostic produces for the categories where drift accumulates.

5. Can this be fixed inside the existing ERP, or does it need something outside it?

Some ERPs support custom fields on a service receipt line that could hold a rate reference, but populating and maintaining those fields requires the contract terms to be extracted, structured and kept current, which is a data problem the ERP itself does not solve. The ERP can hold the comparison once the reference data exists. It cannot generate the reference data from a PDF contract sitting in a shared drive on its own.

Most ERPs used by mid-market manufacturers can technically add a field to a services receipt line. The blocker is rarely the schema. It is that nobody has turned the underlying statement of work, rate card or rebate clause into a value that field can hold.

That extraction work is exactly what a contract compliance audit does: it takes the rate cards, volume tiers, rebate clauses, surcharge schedules and NTE caps buried in vendor contracts and turns them into a structured reference an AP team can check an invoice against. See price file governance for what happens when that reference goes stale even after it exists.

Whether the comparison then happens inside the ERP's native fields, in a bolt-on module, or in a separate review step is a technology choice that comes after the structuring work, not before it. A company that buys a services-receipt module before the contract terms are structured is automating a guess. The sequence matters more than the tool.

6. How should an AP team change the services receipt process without new software?

An AP team can improve a services GRN today by attaching the governing contract term, the specific rate, tier, or cap, to the PO line before work begins, so the approver has something concrete to check against instead of a description. Pair that with a running total against any NTE cap, updated at each receipt, and a required note whenever the receipt amount and the invoice amount diverge. None of this requires new software.

The lowest-cost fix is procedural: require the PO line itself to carry the rate or cap it was negotiated against, not just a dollar amount and a vague scope description. That single change gives the approver a number to check the invoice against instead of relying on memory of what was agreed.

A shared tracker, even a spreadsheet, that logs cumulative billing against a milestone schedule or NTE cap closes the second gap: nobody currently owns the running total across multiple invoices on a long engagement, so a cap can be crossed one invoice at a time with no single moment where it becomes visible.

Requiring a written note whenever a receipt is approved despite not matching the invoice creates the audit trail a controller needs later. This costs nothing but discipline, and it turns an override into a decision on the record instead of a silent exception.

These steps do not replace a structured, contract-linked control. They reduce the exposure while that structuring work gets done, and they make the eventual comparison to n-way invoice matching an incremental change rather than a rebuild.

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

7. Frequently Asked Questions (People Also Ask)

What is a services GRN?

A services GRN is a goods receipt note adapted for service purchase orders. It records that a service, such as labor hours, a site visit or a project milestone, was delivered, so the ERP's three-way match can release payment the same way it would for a physical good.

Why can't three-way matching work properly for service invoices?

Three-way matching compares purchase order, receipt and invoice by quantity and unit price. A service has no physical quantity to count on receipt, so the receipt entry is typically a manually entered approximation rather than an independently verifiable count.

Who is responsible for approving a services GRN?

Usually the requesting manager or a delegate in the business unit that ordered the work, not AP or procurement. They confirm the work happened. They typically have no visibility into the contract's rate card, tier structure or NTE cap.

Does a services GRN catch a rate that no longer matches the contract?

No. A services GRN has no field referencing the contracted rate, so an invoiced rate that has drifted from the rate card passes through as long as someone approves the receipt confirming the work occurred.

What is a digital service receipt, as distinct from a services GRN?

A digital service receipt is a receipt process that compares the invoiced amount against a structured contract reference, a rate, tier or cap, at the moment of receipt, and records any variance. A services GRN confirms presence only; it does not compare against contract terms.

Can our current ERP support a digital service receipt?

Many ERPs can hold a custom field for a rate or cap reference on a service line. The harder part is populating that field with accurate, current contract terms, which requires structuring the underlying contracts first, not a change to the ERP schema.

What should we do before buying software to fix this?

Structure the contract terms, rate cards, volume tiers, rebate clauses, surcharge schedules and NTE caps, into a reference an AP team can check invoices against. Software configured before that structuring work enforces whichever terms were guessed.

How does an NTE cap get missed if every individual receipt looks fine?

An NTE cap is a cumulative limit across the life of an engagement. If no one tracks a running total across multiple invoices, each individual receipt can look correct in isolation while the sum crosses the cap unnoticed.

Is this the same problem as the three-way match gap for goods?

It is related but not identical. The three-way match gap for goods involves a quantity and price that exist but go unchecked against contract terms. For services, there is often no independently verifiable quantity to begin with, which makes the receipt itself unreliable, not just the match against it.

What is the fastest low-cost fix an AP team can make today?

Attach the specific negotiated rate or cap to each services PO line before work starts, so approvers have a concrete number to check invoices against, and require a written note whenever an approved receipt does not match the invoice amount.