WNS Procurement card (P-card) Solution- Implementation experiences

[former_member216093]

Procurement card (P-card) solution from WNS (acquired Bizaps) is one of the bolt-on solutions to SAP, which is known for its smooth integration with SAP. The solution is highly scalable, it can handle multiple card providers at the same time and can process, report and control transactions generated for different companies defined in SAP. In terms of number of card holders, there are no restrictions and any number of users can be given such cards globally.

There are different types of cards such as Embedded cards, Lodge Cards, Travel and Expense cards but this solution has been specifically deployed for Pcards.

Business case: Business case can be put together to highlight the lost opportunities to claim VAT on eligible transactions and to achieve the sufficient level of VAT reclaim to get the return on the P-card implementation project.

Ability to reconcile the statements daily/regularly to the cost objects for commitment visibility, approvals, controls & accruals and to monitor duplicate payments or double charges by vendor through P-card, PO and other modes of payments are some of the tangible benefits coming out of P-card implementation.

Intangible benefits and quick management guidelines can be identified on my previous blog on this subject.

https://scn.sap.com/community/srm/blog/2013/09/17/launching-managing-corporate-procurement-cards-pro...

Process overview: Periodic transaction statements from the card issuer are obtained through a secure connection and uploaded into SAP. These transactions appear into the user’s inbox to further allocate against cost objects (Cost center, WBS, Service orders etc). Once the allocation is completed, those are submitted to be approved by approvers before individual transactions create AP invoices internally within SAP while posting the costs into books of accounts.

Master data: The solution holds master data within IMG config tables for P-cards, their card holders and associated approvers. The solution also holds the default and range of cost objects within which the card holders are allowed to post their transactions. These restrictions can be played very easily to suite to business needs. The solution can be enhanced to block cards so that no further transaction can be uploaded using that card. It also doesn’t need additional user management or roles for card users and approvers as same ECC credentials will be sufficient. In typical business environment, Shared Service Center or Help Desk can maintain master data and followup for monitoring, reporting, controlling and accruals.

Note: Please bear in mind that all these master data configurations are within SAP system and card issuer need to be updated for blocking, unblocking of these cards.

Allowed merchant categories are mapped with the card provider and solution generates merchant Ids out of the uploaded transactions so that future transactions are created on a single merchant ID for reporting purposes.

Tax levels: For card transactions there are different tax levels authorised by HMRC which can be considered as VAT reclaimable. For the benefit of larger audience, I shall clarify that in UK, companies can reclaim VAT from HMRC on those transactions which have got enough details of VAT.

L1: NO VAT details are available on transaction from merchant and therefore VAT receipt is mandatory to consider this transaction for VAT reclaim

L2: VAT details are available at header level from merchant and therefore these transactions are considered as VAT reclaimable

L3: VAT details are available at item level from merchant and therefore these transactions are also considered as VAT reclaimable

Foreign: Foreign transaction are not considered for VAT reclaim

Technical Solution: P-card solution from WNS is capable of handling all types of tax level transactions very well. The solution can be linked to SAP’s Document Management System to ask the users to upload VAT receipts for L1 transactions when they are completing the open transactions to assign cost objects. The business rules to identify different tax levels can also be enhanced.

The solution uses WNS provided BAPI to upload transactions into SAP, these BAPIs are capable of handling different formats provided by card issuer (Like VISA provides transactions in VCF4 format and MasterCard provides these transactions in XML format).

Caution: Please clarify with the card issuer how they identify individual transactions on their file format uniquely and how the header is linked to items. For VCF4 there are guidelines which can be followed as card issuer may have very limited opportunity to negotiate with VISA on transaction details.

The solution can be enhanced to default SAP tax codes based on tax %age at item level so that when the actual transaction is posted on SAP, the SAP has proper tax codes to assign to the transaction. Approvers can reject the items with rejection notes so that card holders correct those errors before the approver finally approves the transaction into SAP accounts.

Testing: The major testing efforts are to test all possible combinations around flagging the transactions with the correct tax levels so that users can identify if a transaction can be considered to reclaim VAT from HMRC and if at all they need to attach VAT receipt to the transaction.

Solution limitation: WNS solution has limitation in terms of showing correct approval history of transactions to the approver; the transaction history for approvers comes as approved for all transactions. Though this is just a reporting issue, the actual rejection process works well and can be followed with the rejection comments from approver.

SAP account postings: The periodic statement is uploaded at aggregate level on a vendor account which is settled with the card issuer within an agreed period (monthly). The individual transactions are then debited to a suspense account which is cleared as those transactions are approved against the cost objects. At the time of approval, SAP generates AP invoice for each individual card transaction which is posted on the cost object (WBS, CC, Internal order etc). Like normal AP invoice all documents are generated and payments are settled against Dummy vendor internally as vendor account for Bank (card issuer) is separate, which is settled periodically (By DD etc). The solution also provides accrual reports for open transactions.

Reports: The WNS solution comes with all standard reports to show outstanding items, merchant spend, suspense balance etc but these reports don’t have any authorisations to play with.

Reporting ROI: Business may need further reporting to know how much VAT they are reclaiming after implementing P-card solution to calculate ROI and which business areas and users they can control better to achieve better results.