IT and professional services controls in Global Shop

Executive Summary

Global Shop Solutions is built around a shop floor: purchase orders, receipts, and jobs. Its AP controls check that an invoice matches a purchase order in quantity and price, and that a receipt exists before payment releases. That logic works cleanly for a bar of steel.

It works poorly for a statement-of-work engagement, a monthly managed-services retainer, or a professional services contract billed in hours, milestones, or a not-to-exceed cap, because none of those have a unit count a receipt can confirm.

The result is not that Global Shop Solutions fails. Its match logic is answering a different question than the one an IT or professional services invoice raises. A purchase order authorizes a dollar amount for consulting services.

An invoice arrives at that same dollar amount. The match passes. Whether the underlying contract capped hourly rates, required milestone sign-off before billing, or set a cap across the whole engagement is not data the match ever touches.

What changes this is not replacing the ERP. It is adding a control that reads the contract itself, the way Global Shop Solutions reads a purchase order line, and checks the invoice against both. Below is what the ERP verifiably does, where that enforcement stops, and how to close the gap without waiting on a system replacement.

1. What does Global Shop Solutions actually check before paying an IT or professional services invoice?

Global Shop Solutions runs invoice approval off its purchase order and receiving modules: an invoice is matched against an open purchase order line for quantity and unit price, and against a recorded receipt confirming the item or service line was received before the invoice can post for payment. For a service PO, the receipt is a manual confirmation that the service occurred, not a quantifiable count, which is where the control's strength for parts becomes its weakness for services.

The purchase order is the anchor. An AP clerk working an IT or professional services invoice in Global Shop Solutions pulls up the PO the invoice references and checks that the invoice's line amount does not exceed what the PO authorized, at the price the PO recorded.

That is a real, working control, and it catches a specific class of error: an invoice billed against a PO that was never issued, or one that bills a higher unit price than what was approved at the time the PO was cut. Both matter and both get caught.

What it does not do is evaluate the invoice against the underlying services agreement. The PO carries a dollar amount and a description line. It does not carry the contract's hourly rate ceiling, its milestone schedule, or a not-to-exceed clause spanning multiple invoices over a project's life. The match logic has nothing to check those against, so it does not.

2. Why does a service purchase order pass a match that still overpays?

A service purchase order in Global Shop Solutions is a single dollar amount tied to a description, not a quantity of a priced unit. An invoice that bills within that dollar amount matches cleanly regardless of whether the underlying hours, rates, or milestones were correct, because the system has no rate table or milestone schedule to compare the invoice against. The contract terms live in a PDF outside the ERP entirely.

Take a statement of work for a fixed total across several months. The purchase order is cut for that total. Each month, the vendor invoices a piece of it. As long as the running total stays under the PO ceiling, every invoice matches.

Nothing in that sequence checks whether the vendor billed the contracted hourly rate for each consultant level, whether a milestone was actually delivered before its associated invoice, or whether a rate escalation clause kicked in without approval. The PO ceiling is a budget check, not a rate check.

This is not a defect specific to Global Shop Solutions. It is true of PO-based matching generally: the system enforces what is written into the PO record, and a services contract's real terms rarely make it into that record in a form the system can evaluate line by line.

3. Where does three-way matching stop working for milestone and retainer billing?

Three-way matching ties an invoice to a purchase order and a receipt. For a physical good, the receipt confirms a countable quantity arrived. For a milestone or retainer service, the closest equivalent is a manual sign-off with no independent count behind it, so the receipt step confirms only that someone approved the invoice, not that the milestone was met or the retainer's scope was fully delivered that period.

The receipt field exists in Global Shop Solutions for both goods and services, but what it means changes entirely between the two. For a shipment of parts, receiving a quantity is an objective, countable act.

For a service line, the same field gets checked off by whoever reviews the invoice, based on their own judgment that the work happened. That is not a flaw in the software. It reflects a genuine difference between a countable good and a delivered service, and the ERP's field was not designed to resolve that difference.

A. Milestone billing

A milestone invoice bills on a date or a deliverable, not a quantity. Global Shop Solutions records a receipt against the PO line, but the person entering it is confirming an invoice arrived, not independently verifying the deliverable against the statement of work's acceptance criteria. The control and the underlying obligation are two different checks wearing the same name.

B. Retainer billing

A flat monthly retainer for managed IT services bills the same amount whether the vendor delivered the full scope of hours or a fraction of it. The PO match confirms the invoiced amount equals the retainer figure. It does not confirm the vendor met a response-time commitment or delivered the ticket volume the retainer assumes, because that comparison requires the contract's service-level terms, which sit outside any field the match logic reads.

4. What contract terms sit outside anything Global Shop Solutions can enforce?

Rate cards by consultant level, not-to-exceed caps spanning an entire engagement rather than a single invoice, milestone acceptance criteria, and renewal-triggered rate escalations all live in the services contract as unstructured text or a schedule attached to it. None of these are fields the purchase order or receipt modules carry, so no match rule in the ERP can compare an invoice line against them.

These terms are not missing because someone forgot to configure a field. They are missing because a purchase order system is built to authorize spend against a description and a ceiling, not to encode a full services contract's structure.

That gap is consistent across PO-based ERPs generally, not unique to Global Shop Solutions. Closing it means reading the contract separately and checking invoices against it as its own step, not waiting for a system upgrade to add contract fields that were never part of the design.

• Rate cards by role: A contract naming different hourly rates for a principal, a senior consultant, and a junior analyst has no equivalent field on a PO line, which carries one price.
• Engagement-wide NTE caps: A not-to-exceed clause covering the full engagement across many invoices is not the same as a single PO's dollar ceiling, and nothing forces the two to reconcile automatically.
• Milestone acceptance criteria: Whether a deliverable actually met the contract's definition of complete is a judgment call the receipt step does not make.
• Rate escalation clauses: A renewal or anniversary date that triggers a new rate has no field to compare the current invoice's rate against the date it took effect.

5. Can a controller close this gap without replacing Global Shop Solutions?

Yes. The fix is not a new ERP, it is a control layer that reads the services contract the way the ERP reads a purchase order, then checks the invoice against both records before payment. That layer can run as a periodic audit against historical invoices or as a standing check against new ones, and either way it does not require touching Global Shop Solutions configuration.

The purchase order and receipt modules in Global Shop Solutions are not going anywhere, and they should not be. They correctly enforce what they were built to enforce: budget ceilings and confirmation that something was received.

The missing layer is contract-to-invoice matching: taking the actual services agreement, extracting its rate card, its NTE terms, its milestone schedule, and comparing each invoice against those specific terms rather than against a single PO dollar amount.

A rate card comparison catches rate creep on a specific consultant level. An NTE comparison catches an engagement that quietly exceeded its total cap across several invoices that each individually passed. Neither requires new fields in the ERP. Both require someone, or some process, reading the contract the ERP never sees.

6. Should this be a one-time audit or a standing check?

A one-time retrospective audit finds leakage already embedded in 12 to 18 months of historical spend, across ValueXPA diagnostics, and answers whether the problem is material before committing to a standing process. A standing check then prevents the same drift from recurring on future invoices. The two are sequential, not competing choices, and the first should inform whether the second is worth building.

Running a retrospective pass first answers a question a controller needs answered before investing further: is IT and professional services spend actually leaking against contract terms. That answer should come from looking at the actual invoices and the actual contracts side by side, not from assuming the answer because the ERP's match logic has a known limitation.

If that review finds material, recurring drift, it makes the case for a standing check, one that runs on new invoices as they arrive rather than waiting for a periodic look-back.

Sequencing that decision the same way applies across more than one spend category, not just IT and professional services. For the wider pattern this sits inside, start with the margin drift guide.

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

7. Frequently Asked Questions (People Also Ask)

Does Global Shop Solutions support three-way matching for service invoices?

Yes, technically. The PO and receipt modules apply to service lines the same way they apply to goods. But the receipt step for a service is a manual sign-off, not an independent count, so the match confirms an invoice arrived, not that the contracted work was actually delivered as specified.

Can Global Shop Solutions enforce a not-to-exceed clause across an engagement?

Only at the level of a single purchase order's dollar ceiling. It cannot track a not-to-exceed cap written into a services contract that spans multiple POs or multiple invoices issued over the life of an engagement, because that comparison requires reading the contract, not just the PO record.

Why does an invoice with the correct total still violate the contract?

Because the PO match checks the invoice against the PO's dollar amount, not against the contract's rate card, milestone schedule, or escalation clauses. An invoice can total the exact PO amount while billing the wrong hourly rate for a given consultant level.

Is this a Global Shop Solutions-specific problem?

No. Any PO-based ERP faces the same structural gap on service spend, because purchase order and receipt fields were designed to authorize and confirm physical goods, not to encode a services contract's rate cards, milestones, and caps.

What does a contract-to-invoice matching layer actually compare?

It reads the services agreement itself, its rate card by role, its milestone schedule, its NTE terms, and checks each invoice line against those specific terms, rather than against a single PO dollar ceiling the way Global Shop Solutions does.

Should we fix this by reconfiguring Global Shop Solutions?

The PO and receipt modules are not misconfigured. They enforce budget ceilings and delivery confirmation correctly. The fix is an added control layer that reads the contract, not a change to how the existing modules work.

How do we know if this is worth addressing for our IT and professional services spend?

Run a retrospective review of actual invoices against actual contract terms first. That review shows whether drift is material before a standing check is built to catch it going forward.

Does a receipt in Global Shop Solutions confirm a milestone was met?

No. It confirms that whoever entered the receipt believes an invoice arrived for work performed. It does not independently verify that a deliverable met the statement of work's acceptance criteria.