Separation of Duties

Separation of duties means that no single employee has the responsibility and/or system access to complete every step (or too many steps) of a process related to organization finances, payments, sensitive information, etc. To protect against fraud, such processes should involve two or more employees. When this is absolutely not possible due to staffing limitations, it is crucial to implement compensating controls, such as reports that are reviewed by someone in a management role.

In regard to P-Card program management, examples of duties that should be separated include:

  • Requesting a card from the issuer and receiving the card (then distributing to the cardholder); it would be better to have a new card sent directly to the cardholder and then have someone else review new cards/accounts opened each month

  • Downloading transactions from the issuer and uploading the file into the finance system; see the example below

  • Preparing documentation for a payment to the issuer and executing the payment within the accounting system

Ideally, a card program manager/administrator (PM/PA) should not have administrator access to both the issuer’s system and their organization’s finance/accounting system.

In addition, no cardholder should be allowed to “self approve” their transactions. The cardholder (or a delegate) should perform transaction reconciliation and someone who is at least one functional job level higher than the cardholder should fulfill the approving manager role.

Related Resources

Don't forget to subscribe to the blog (no charge) to receive educational content!

Example: A Separation of Duties Dilemma

An auditor who used the Recharged Education P-Card risk analysis template asked for advice because, within her organization, one AP clerk performed accounting-related tasks that the template says should be split among two or three people. She described how this employee was responsible for:

  1. downloading the file of reconciled transaction data from the card issuer’s system,

  2. making any necessary corrections to account/budget codes within the file, and

  3. uploading the corrected file into their accounting/finance system

Risks

Within the text file format (.txt)—the format of the interface file downloaded from the issuer—someone can change any part of the data, not just account/budget codes; for example, changing the name of a vendor to hide where someone made a purchase. Rarely are there any records or reports of the changes made within this file.

Suggestions

  • Make every effort to separate the duties and/or establish the appropriate oversight.

  • Avoid making any changes within the downloaded interface file. Besides the risks noted above, it is too easy to accidentally do something that shifts the data, which can cause problems when uploading to the accounting system. Make the necessary corrections after the file is uploaded.

  • Inquire about the ability of the accounting system to produce an audit trail—a record or report—of changes made. If one is available, a supervisor should review it.

  • Compare reports from the card issuer’s system to reports from the accounting/finance system to ensure accuracy. At least do some spot checking concerning vendor and/or cardholder totals. For example, if a report from the card issuer shows John Smith spent $3,100 for the cycle, verify against the accounting system. This type of activity should be completed by someone who is not involved with the three steps noted above.

  • Finally, contact cardholders and their manager-approvers about any coding errors, so they can learn from the mistakes.