One­Time­Ven­dors (Conto pro Di­verse, CpD)

In procurement or vendor subledger it can be exciting to analyze „OneTimeVendors”.

Let´s have a look to a standard process in procurement when ordering hardware for example. Task will be to find a vendor who supplies laptops for the company in the future. An approach could be as follows:

1. Several inquiries with existing vendors for laptops
2. Depending on the terms of the offer, the best/cheapest vendor is chosen
3. In order to enter the order, the vendor is looked up in the system, to see, if already existing.
   
   • In case that the vendor does not exist in the system, a master data record stating name, address, bank details etc. is saved and the vendor gets a unique vendor number
   • If the vendor is listed in the system, the existing master data record is used.
4. An order is created that refers to the vendor or vendor number respectively; subsequent documents as incoming invoice and goods receipt will be handled the same way.

However, there are situations where the effort is not worth it. A typical example are costs for application and their refunds respectively.

If for the journey of a candidate, such as a train ticket in the amount of 15.00 Euro, refunds will be made, the internal costs of the establishment of a master record would exceed the transaction value by far. Furthermore this record will not be needed lateron, as it is a one-time process.

In this case OneTimeVendor accounts are a useful device. As a special collective account such one-time processes can be posted to. A typical naming convention for such account would be “CpD A-K” for example, where a fictitious vendor number 1000 would be posted to, and fictitious vendor number 2000 posted to “CpD L-Z”.

The invoice for candidate „Toni Test“ could be posted to vendor number 2000, without creating a vendor master record. Reimbursement of expenses for "Stefan Senseless" is also posted to the vendor number 2000, as well as the night of the manager in the "NA Hotel Leipzig" as part of a cancelled flight. Various ("Miscellaneous") transactions are therefore gathered under a single vendor number.

As the account CpD-vendor is only a shell, the actual data for each transaction must be saved ad hoc, often when receiving or posting the invoice.

Typical features of processes posted to CpD-accounts can be

• One-time: only business with these partners made only once
• Small amount: In general, only small value transactions are handled
• Ad-Hoc entry: The master record as collective account is only general, details of the invoice have to be entered during posting.

An­a­ly­tic ap­proach­es

From these characteristics and features conversely result the risks that have to be reviewed via data analytics. The essential issue with collecting a lot of business processes in one CpD-Account is, that transparancy gets lost, as shown in the figures with matches. It increases the risk of errors or fraudulent conduct.

Typical audit question would be:

Have re­cur­ring trans­ac­tions been pos­ted to CpD?

Have the transactions to the same business partners been posted repeatedly to a collective account?

--> Then, a separate master record should be created because the one-time character does not exist any longer.

Have big sing­le amounts been pos­ted to CpD?

Have big single amounts been posted to CpD? --> In this case it is recommended to enter an entire master record to prevent that big amounts disappear in the reporting, but to be able to identify each business partner number explicitly.

Have exis­ting ven­dors (in du­pli­cate) been pos­ted to CpD also?

Have the recipient data, especially the bank details, been registered correctly, or is there perhaps even a master record? (--> Manual entries increase the risk of errors and thus pecuniary loss or duplicate payments.)

Are there any ab­nor­ma­li­ties in the pay­ees?

How is segregation of duties ensured, as the person who creates the master record and enters the invoice “merge”? (--> Especially risky when entering bank details ad hoc.)

The term "one-time vendor" thus means the collective accounts to which one-time transactions should be posted. These transactions should be considered in more detail by means of analysis. There are several exciting approaches in this context.