In addition to configuration requirements described in the previous sections, requirements vary based on whether you're integrating into an ERP or ecommerce environment.

Ecommerce integrations integrate into the accounts receivable side.

ERP integrations must integrate into both the accounts payable and accounts receivable sides.

Ecommerce

Ecommerce integrations typically only touch the accounts receivable (AR) side of an accounting system. Tax is straightforward. You know how much you're going to charge for a product and how much the tax is going to be.

ERPs

ERPs will also touch the AR side of an accounting system. And similar to ecommerce, tax determination is straightforward.

In addition to the AR side, ERPs will touch the accounts payable (AP) side as well. The challenge on the AP side is that the AP side pulls data from multiple systems, including logistics systems, trade systems, and retail systems.

Logistics systems

A logistics system interfaces with a terminal operating software when lifting fuel out of the terminal. A purchase order will come in from an EDI, and the structure for the EDI can be different between different companies. On the AP side, you can call ATE to verify the taxes charged on the invoice. If the amounts don't match, the invoice can still clear if the difference is below a certain threshold (for example $10 or $20), or it may have to go to a tax analyst's desk to determine the reason behind the difference between what the vendor charged and the amount that came through your system. For AP systems, there are multiple terminal operator systems. An integration into your ERPs AP side must provide a way to determine where the source data originated.

Trade systems

Trade systems provide information about where a product is physically located at different portions of a distribution chain. For example, when oil is offloaded into a refinery, typically federal oil spill tax is then charged, and that tax is passed down to the consumer. Trading happens when fuel leaves the refinery and enters the main distribution pipelines, for example, when fuel travels down a pipeline from OK to TX. In this case, trade occurs back and forth, and sourcing the origin and destination of the fuel is easy. But when trading midstream, you need to be able to model the data coming in to ATE to be able to tax it correctly. You also want to check that part of the supply chain to verify the seller and buyer licenses. If either entity in the trade isn't licensed correctly with the IRS, the trade is immediately broken. Once broken, you’ll be required to pay road tax on a bulk trade inside the pipeline. The way the data comes into the system depends on the trading system and which inventory management software they're connecting to. If you have a logistics table inside the ERP that the AP side can hook into, then you can use ATE for tax determination.

Retail systems

Retail systems include fuel for consumers from gas stations or fuel located on site at operating sites (drilling, agriculture, and so on). When fuel crosses a terminal flange and enters a truck then in most states, it has broken bulk and taxes are due. The supplier filling the truck is responsible for paying taxes to the required jurisdictions (including the federal government). From there, the price for fuel is determined: points per gallon for fuel pulled from a particular terminal at a particular time. When an order for fuel comes in, an operator is able to source fuel from a specific terminal for a specific price, and the fuel will go to a specific location. A truck will then drive to the retail gas station, drilling operation, and so on At this point, those receiving entities will pay line item excise tax for the fuel. Then at the retail location, the excise tax is included in the product price and passed on to the consumer.

ERP vs ecommerce requirements