Surcharge Sunset Dating as a Control

Margin drift is the gap between what a vendor contract says and what the invoice actually charges. Surcharge sunset dating is one narrow but persistent example: a fuel surcharge, a temporary accessorial fee, or a market-adjustment line item gets added to a rate card with an expiration condition attached, and the invoice keeps charging it anyway.

This guide covers what sunset dating means, why it fails silently, and how to build it into a repeatable control rather than a one-time cleanup.

What is surcharge sunset dating?

Surcharge sunset dating is the practice of attaching an expiration condition to a temporary charge on a vendor contract or rate card: a calendar date, a market index threshold, or a volume trigger after which the surcharge should stop or step down. It exists because surcharges are meant to be temporary responses to a cost spike, not permanent price increases. The control is the mechanism that checks whether the invoice actually stops charging it once the condition is met.

A surcharge usually enters a contract as a rider: a side letter, an email confirmation, or a clause buried in an appendix rather than the main rate schedule. It says something like "this fuel surcharge applies while diesel exceeds $X per gallon" or "this expedite fee applies through Q2."

The expiration condition is written once, at the point the surcharge is added. Nothing in a standard AP workflow re-checks that condition on a recurring basis by default. The invoice keeps arriving with the same line item, and unless someone deliberately compares the current invoice against the original rider, the charge continues.

This is a contract compliance problem, not a pricing dispute. The vendor is not necessarily doing anything deliberate. The charge was correct on the day it was added. It becomes incorrect only when a condition elsewhere, a date passing or an index falling, is met and nobody on the buyer's side is watching for it.

Why does this charge survive after the condition is met?

A surcharge survives past its sunset date because the systems that would catch it are not built to test that condition. Three-way matching checks the invoice against the purchase order and the receipt; it does not test whether a market index moved or a calendar date passed. The rate card in the ERP reflects the charge as it existed at setup, not as a conditional rule that changes state over time.

Purchase orders and receipts confirm that a shipment happened and a quantity matches. They say nothing about whether the price applied to that shipment is still the price that should apply. A surcharge with an expiration condition is a rule that changes state over time, and three-way matching checks static facts, not time-dependent ones.

The rider itself is often stored outside the system that generates the invoice. It might live in a signed PDF, an email thread, or a paper file. The ERP's rate table reflects whatever was keyed in when the surcharge started. Nothing in the system updates that table when the expiration condition is met, because nothing in the system is watching for the condition.

The result is a charge that was correct when it was created and incorrect indefinitely afterward, with no natural trigger to catch the change. It persists because everything upstream of the invoice is functioning as designed.

Which surcharge types can carry a sunset condition?

Fuel and energy surcharges tied to a published index, expedite or rush fees tied to a project timeline, market-adjustment surcharges tied to a commodity price, and temporary capacity or peak-season fees are categories that can carry an expiration condition. Each ties the charge to something external: a date, an index level, or a project milestone, and each requires someone to track that external condition independently of the invoice.

Fuel and energy surcharges are often tied to a published index like the DAT freight rate index or the US EIA diesel price series, with a stated trigger level. When the index crosses back below the trigger, the surcharge is supposed to adjust.

Expedite and rush fees attach to a specific project phase or delivery window. Once that window closes, the fee has no basis to continue, but it can roll into the standard rate if nobody flags the end date.

Market-adjustment surcharges, used in metal fabrication and plastics where a raw material input cost spikes, are tied to a commodity price level rather than a calendar date. These are harder to track because the trigger moves continuously rather than expiring on a fixed day.

Each of these categories shares the same structural weakness: the condition governing the charge lives outside the invoice and outside the ERP's static rate table, which is where a control needs to be built to catch the miss.

How do you build sunset dating into a working control?

Building sunset dating into a control means listing every active surcharge with its expiration condition in one place, assigning a named owner to check that condition on a fixed cadence, and requiring the invoice to be matched against the current condition, not just the original rate card. The condition itself, whether a date, an index level, or a milestone, has to be tracked independently of the invoice stream.

Start with an inventory. Pull every rider, side letter, and email confirmation that added a surcharge, and record the expiration condition in a single register: vendor, surcharge type, trigger condition, and the source document. If this register does not exist, no control can run against it.

Assign an owner and a cadence. A date-based surcharge needs a calendar check. An index-based surcharge needs someone checking the index on the schedule the contract specifies, monthly or quarterly, against the trigger level in the register.

Match the invoice against the current state of the condition, not against the rate table as originally keyed in. This is the step that is easy to miss: the invoice gets checked against what the ERP has stored, and the ERP reflects the surcharge's starting state, not its current one.

When a condition is met, the credit or rate change has to be requested from the vendor, not assumed. The buyer has to raise it, cite the original rider, and request the adjustment or a credit memo for the period the charge continued incorrectly.

Can AP automation catch an expired surcharge on its own?

AP automation software validates invoices against purchase orders and receipts at the point of entry; it does not interpret an expiration clause sitting in a side letter outside the ERP. It can enforce a rule once that rule is coded into the system, but coding the rule requires someone to have already read the rider and translated the condition into a check. The software prevents future errors; it does not read contracts.

AP automation platforms are built to catch discrepancies between what was ordered, received, and billed. That is a valuable and different job. It stops duplicate invoices, quantity mismatches, and price differences from a stored rate card.

What it does not do on its own is notice that a fuel index fell below a trigger level written in a rider months ago, or that an expedite fee's project window closed last quarter. Those facts live in unstructured documents outside the ERP, and nobody has translated them into a system rule.

A one-time review can surface every unexpired-in-name-only surcharge sitting in current spend. It can also write out each expiration condition in plain terms so a rate table or a rule set can be updated with it. Turning that written rule into an ongoing check inside a given AP automation platform is then a configuration task for whoever owns that platform, not a capability this guide is claiming on its own.

What should you do if you find an expired surcharge on your own invoices?

Pull the original rider or contract language for the surcharge, confirm the expiration condition and the date or index level it references, and calculate the amount charged since that condition was met. Then request a credit memo from the vendor citing the specific clause, not a general billing dispute. Document the finding so the same surcharge does not silently reappear on a future invoice.

The first step is always the source document, not the invoice. The invoice only shows what was charged. The rider shows what should have happened once the condition was met, and it is the basis a vendor will accept for a credit request.

Calculate the exposure across the full period the surcharge continued past its expiration, not just the most recent invoice. A surcharge that missed its sunset date several months ago has been overcharging on every invoice since, and a vendor will generally credit only the period you can document with dates and amounts.

When requesting the credit, cite the clause number or the rider date directly. A vague request to review this charge is easy for a vendor's AP team to deprioritize. A specific citation with the dollar amount attached is not.

Finally, add the surcharge to a tracked register so the same expiration condition is checked again the next time it is relevant, whether that is a recurring seasonal fee or an index that could cross the trigger level again in either direction.

For the wider pattern this sits inside, start with the margin drift guide. See also shift and overtime premium misuse and freight and 3pl audit.