Category Archives: Procurement Innovation

A Hitchhiker’s Guide to e-Procurement: Reconciliation, Part II

Mostly Harmless, Part XIII

Previous Post

In the last post, reconciliation was defined as the process of comparing and matching figures from the accounting records of one system with the accounting records of another system. This meant that records in the system not only needed to match up, but match any associated records in the inventory system, the human resources system (if temp labor was procured), and the records in the supplier systems. This often requires a number of challenges to be overcome. This post will address some of the challenges of reconciliation, some associated best practices, and a few of the benefits that could be expected from an appropriate e-Procurement solution.

Common Challenges

  • Manual SKU Assignment

    If a line item can not be automatically matched with a purchase order line item and a corresponding price, then it can be difficult to match an item with the proper item in the buyer’s system.

  • Overpayment Identification

    As explained in the previous post, sometimes overpayments will slip through the most controlled system, especially if it’s difficult to match a conditional discount against a line item or if a contract is late being entered into the system.

  • Tax Verification

    Is the tax rate correct? Are the items being taxed subject to taxation? Is the organization exempt? Is the organization eligible to recover (part of the) tax payment? These can all be difficult questions to answer.

Best Practices

  • Flagging of Manual Assignments

    The system should automatically flag any manual assignment, and queue any manual assignments above a certain value for supervisory review.

  • Automatic Identification of Potential Overpayments

    The system should automatically identify any off-contract payments for goods and services that relate to existing contracts with suppliers in case the goods or services were covered by general discount clauses or in case the opportunity arises to negotiate them into a (future) contract revision.

  • Automatic Tax Rate Verification

    The system should automatically verify that the tax rates used are correct, that each tax the organization knows it has to pay is included, and that any taxes it gets to reclaim are appropriately flagged.

Potential Benefits

  • Overpayment Detection and Recovery

    Good reconciliation support will increases the number of overpayments that are detected and increase the chance of full and timely recovery.

  • Tax Recovery

    Good reconciliation support will increase the chances that recoverable tax payments are identified.

Once the reconciliation phase is complete, it is time to reclaim any tax payments to which the organization is due, which is the subject of a future post.

Next Post: Payments

Share This on Linked In

A Hitchhiker’s Guide to e-Procurement: Reconciliation, Part I

Mostly Harmless, Part XII

Previous Post

Reconciliation is the process of comparing and matching figures from the accounting records of one system with the accounting records of another system. In e-Procurement, it generally refers to the reconciliation of the invoice and associated payments against goods receipts, purchase orders, contracts, and / or tax records.

While reconciliation should be done at each step of the process — as the purchase order should be matched against the approval and a contract, the goods receipt against the purchase order(s), and the invoice against the goods receipt(s) and the purchase order(s), there should be a separate, (semi-)manual reconciliation phase as not everything can be reconciled automatically and there will always be new situations and exceptions not accounted for in the automatic rules.

If there is an error in a SKU or other identifying attribute, it may not be possible to automatically match one or more invoice line items against the purchase order(s) they correspond to. In this situation, the e-Procurement system would flag the invoice for manual review, at which point the individual who (first) processed the invoice would do a manual match. If the amount is significant, this match should be rechecked at a later time, because if there were two similar items in the procurement system (catalogs) and the match was made to the wrong, off-contract item, the organization might end up paying a higher price.

A review should also be made of all purchases against a supplier’s account for which there are no contract prices if there are contracts in place with the supplier. For example, a contract with an electronics vendor might be such that the organization gets 10% off of list price for all items for which a contract price is not specified or that the organization gets 15% off of all purchases once it has purchased One Million Dollars worth of goods and services. These situations may not be caught by the system automatically as it might not be easy to encode which goods or services are covered, especially if items are being ordered / purchased not yet in the system.

In addition, a review should be made of all tax payments. Is the tax rate correct? Are the items being taxed subject to taxation? Is the organization exempt? Is the organization eligible to recover some of the payments (such as GST in Canada)? This is a difficult subject and a manual review will be required to ensure that the right taxes are being made at the right amount and that the organization is capturing the right information that will be required for tax reclamation, which is the subject of an upcoming post.

Next Post: Reconciliation, Part I

Share This on Linked In

Hackett, Hast Thou Forsaken Us?

I was very disappointed after reading this recent article on “process matters too” in the CPO Agenda which discussed the recent findings of The Hackett Group with respect to P2P transactional channels as well as their recommendations for procurement organizations wanting to improve overall source-to-settle performance. If the article is to be believed, Hackett has fallen for the classification trap.

According to the article, Hackett says that a company must:

  1. Possess a unified spend category taxonomy.
  2. Define a rationalized set of transactional purchasing and payment processes that are then explicitly mapped to spend categories and/or associated suppliers.
  3. Ensure that individual P2P transactional channels balance cash, cost and stakeholder satisfaction.
  4. Integrate a channel strategy selection and implementation plan into the category management process.

In reality:

  1. A single taxonomy is not enough as each business unit will need its own in order to be effective. Moreover, taxonomy is irrelevant. The only thing that is important is that the spend is captured and available for analysis. Every department and user will want to see the data rolled up differently. This is the classification trap, and those who fall into it never advance to real data analysis, which is where true savings are discovered.
  2. While the company must define an accepted set of purchasing and payment processes, and while spend must be associated with the appropriate suppliers, the mapping should not be made to an explicit fixed category. Assignments must be able to change as needs change (spend by supplier, spend by commodity, spend by category).
  3. Channels must balance cost and stakeholder satisfaction, but the amount of cash flowing through is not relevant. If the cost of maintaining the channel is too high (relative to the value), the channel must be abandoned.
  4. This is good advice. Planning greatly increases the chance of success.

So, if you really want P2P success:

  • Come up with a channel plan.
  • Implement the appropriate channels and insure all spend goes through an approved channel.
  • Make sure all of the spend data is accessible from each channel.
  • Analyze the data in a true data analysis tool to determine which channels are performing well, which aren’t, and adjust the plan over time as necessary, and
  • allow each business unit to use their own taxonomy.

Share This on Linked In

A Hitchhiker’s Guide to e-Procurement: Invoices, Part II

Mostly Harmless, Part XI

Previous Post

In the last post, the invoice was defined as well as some of the associated data requirements. This post will address the associated challenges with invoice processing, some associated best practices, and the benefits that could be expected from an appropriate e-Procurement solution that was flexible and efficient in its processing of invoices.

Common Challenges

  • Purchase Order Partitioning

    The line items on the invoice can relate to one or more purchase orders … but which items go with which purchase orders? If an invoice is for a large shipment of hundreds of line items, this can be a challenge.

  • Billing Validation

    Were all of the items ordered? Were they received in acceptable condition? Are they at contracted or otherwise agreed to rates? Do any discounts apply? Are there early payment discounts to be taken advantage of?

  • Duplicate Detection

    Is this invoice unique? Is each line item a unique billing against received goods?

Best Practices

  • Automatic Acceptance / Import

    The system should be capable of automatically receiving invoices from suppliers and automatically accepting them (conditionally) if no reason for automatic rejection is found.

  • Automatic Uniqueness Validation

    The system should automatically match each line item of the invoice against the indicated and/or outstanding purchase orders and automatically reject the invoice if it, or any part of it, is determined to be a duplicate of an already submitted, and (conditionally) accepted, invoice. This notice should automatically be sent to the supplier, along with the reason for rejection.

  • Automatic m-Way Matching

    As soon as an invoice is received, it should be matched against any and all relevant goods receipts, purchase orders, and contracts to make sure that all goods were ordered, received, and billed at contracted rates. If unacceptable errors are found, the invoice should be automatically rejected. If only minor (billing) errors are found, the invoice should be accepted with modifications. If one or more items are under dispute, the invoice should be conditionally accepted and a note made that it can not be paid automatically until the dispute is resolved and that manual intervention will be required if this resolution does not occur before the due date. If one or more line items can’t be matched, the invoice needs to be flagged for manual review.

Potential Benefits

  • Reduced Overspending

    Automatic uniqueness validation insures that duplicate payments are not made, automatic m-way matching prevents overpayments, and automatic flagging of invoices under disputes prevents payments for unacceptable merchandise.

  • Faster Payments

    Invoices that are determined to be problem free can be queued for payments according to the payment terms. Automatic payments can prevent interest charges or reduced goodwill on the part of the supplier.

  • Greater Savings

    The prevention of duplicate payments, overpayments, and payments for goods not yet accepted, the ability to take advantage of early payment discounts, and increased supplier goodwill all contribute to greater savings.

Once the invoices are accepted, it is time for final reconciliation of (conditionally) accepted invoices and invoices that are marked for manual reconciliation (due to one or more problems that are not cause for automatic rejection), which is the subject of the next post.

Next Post: Reconciliation, Part I

Share This on Linked In

A Hitchhiker’s Guide to e-Procurement: Invoices, Part I

Mostly Harmless, Part X

Previous Post

A (sales) invoice is a commercial document issued by a seller to a buyer that indicates the products, quantities, and prices for products and services the seller has provided to the buyer. An invoice indicates that the buyer must pay the seller according to payment terms. While the purchase order is the most important document to the buyer, as it outlines what the buyer is willing to buy (and at what price), an invoice is the most important document to the seller, as it represents money due to the supplier for goods and services rendered.

An invoice is generally the result of a purchase order, but the relationship is not necessarily one-to-one. A supplier might fulfill an order with multiple shipments (especially if some items are not immediately available) and invoice after each shipment, indicating that there can be many invoices corresponding to one purchase order. In addition, a supplier might fulfill multiple purchase orders at once, if the orders were small (and the supplier is responsible for all shipping charges over an agreed amount), indicating that there can be many purchase orders corresponding to one invoice.

Like a purchase order, an invoice must contain a significant amount of information, including items delivered, associated SKUs, billing rates, adjusted rates, reasons for adjustments, corresponding purchase order(s), corresponding goods receipt(s) (if available), invoice date, delivery dates, unique identifiers, taxes, tax codes (state vs. federal vs. VAT etc.), descriptions, billing address, payment address, contacts (for disputes), and payment terms.

In addition, it must contain any information required for m-way matching, to insure that only the items that were ordered and delivered are paid for, and only at contracted rates, and adjusted rate calculations if line-item or global discounts apply (because a volume threshold was reached, because the buyer opted to pay early to take advantage of an early payment discount, or because the supplier agreed to a discount to resolve a dispute).

Furthermore, just like the goods receipt must be representable in a universal (e.g. XML) format that can be accepted by all of the systems that require it, so must the invoice, as the buyer may need to return the invoice to the supplier after adjustments (subject to contract terms and/or agreements that resulted from a dispute resolution) are made.

Thus, when a buyer is evaluating an e-Procurement system, extra attention must be paid to the invoicing capability as it not only has to support m-way matching (with contracts, purchase orders, and goods receipts), but support revisions and automated communications with the supplier. Some of these topics will be addressed in more detail in the next post.

Next Post: Invoices, Part I

Share This on Linked In