Cap and Trade Options

Our clients have reacted to the California Cap and Trade fees in various ways. Here is a recap of what has been developed:

1. Bury it and leave it hidden in price.
2. Bury it, but present it on the invoice like a tax, perhaps only for specific accounts.
3. Add it as a line item on the invoice, with double receipts.
4. Add it as a line item on the invoice, carrying the fee as a new item into A/P.
5. Add it as a profile tax.

The most common response is just to book fuels with the fee in cost. This leaves no trace of the fee in the system or on invoices to customers.

A variation that might warrant broader adoption: invoices support the presentation of a fee in the section itemizing the taxes added to product price. This requires linking the fuels sold to a fee product, under which pricing is maintained for the Carbon fee. Typically, this would be the OPIS average fee, by day, by fuel. All such fees are still buried in cost at receipts. But for some or all customers, the bulk invoices present the price as reduced by this “published” fee that was in effect on the delivery date — even if that’s not the fee paid when the product was acquired, whether because a vendor didn’t match OPIS, or because the purchase didn’t occur on the delivery date.

One client commissioned the coding needed to receipt the fuels without the fees in cost, to receipt the fees into a separate product, then to have the order automatically add extra lines for the fees. They then had to customize their quotes to achieve the same effect. Cardlock fuels could not follow suit with this method, and so those fuels had to carry the fees in cost. In the end, the client reverted to method #1.

One client had us add the Carbon fee as a new component of a receipt, somewhat like Freight. The fuel is receipted exempt all taxes and fees. The receipts journal calculates the fee from supplier pricing, then passes that on to A/P. The A/P BOL module finds and vouchers the fee. Order entry was patched to add one or more lines to a fuel order for the Carbon fees. The client took this live, and then reverted to #1 after receiving feedback from their customers.

One client has successfully treated the Carbon fees like a tax. This required us to expand the memory of tax rates from current, plus 3 priors, to an unlimited history. That, in turn, required this client to be at software version 3.0, as this expansion of tax rate history was invasive to many parts of the system and could not be installed as an overlay on older code. Tax rates are changed daily. One downside is that variation by vendor either requires adjustments in A/P, or extra tax profiles to handle variation by supplier at the same rack. This client doesn’t run cardlock, and so never had to consider how to make that work with this method.

The bottom line: almost everyone just hides it in cost and price, but it’s proven reasonable to patch the invoice print to present a breakout, within limits. Figure that’s a 2-3 hour patch to make, assuming we’re dealing with standard invoice print programs.