I'm a new Concur user and have a few questions I hope someone can help with.
During any month, credit card transactions for a month typically do not get fully approved and submitted in the same periond. We therefore have some unassigned and unsubmitted charges.
The approved charges get posted to our accounting sytem via an upload, resulting a debit to the appropriate expense a/c and a credit to AP. Bear in mind that the amount charged to AP will be less than the amount shown as current month charges per statement due to unassigned/unsubmitted transactions.
We pay the credit card company in full but that payment can only be partially applied to the AP credit from the upload, leaving an inapplied credit in the vendor account.
We post a reversing entry to accrue for unassigned/unsubmitted transactions and post an entry to account for any previously unassigned/unsubmitted transactions which have since been submitted in Concur.
The challenge noted here is that AP will not be corret until ALL charges are posted to the account.
I'd like to know how you post your transactions as this doesn't appear to be the most efficient means. Thanks in advance!
We do what you do. We ensure managers approve reports timely or their VPs find out through the notification function in Concur. Our expense processors also do a great job following up as well as they are responsible for accural entry.
We aren't statement based (CBS), so charges are available for processing by employees immediately. This helps quite a bit as an employee doesn't have to wait until the end of the month to do their expense report.
Basically, we do the same. We have a custom report that shows all the transactions in Concur so we can tie to the bank statement. If someone has not submitted, we contact them to do that by a certain day of the month - the 28th unless a holiday - and if they do not submit, all of their charges go to their defaults. Clearly, managers in charge of budgets do assist in getting the employee to submit on time.
My company currently is using a CBCP card program, and we came up with this process due to the very issue you described. Very likely, not all card activity will be reconciled correctly on reports and approved before the cycle needs to post onto the ledger, and we needed a way to capture all activity, not just what was submitted.
As such, we do not use the batch export files as a means for recording values, but rather we created a custom process that uses a few custom reports run out of Analysis / Cognos. These reports gather information on all credit card transactions that posted within our billing cycle and then we compile those reports together to create a master upload into our ledger. There might be a simpler way to accomplish this in Professional, but since we're on Standard we've had to use what was available.
We have four reports that are run:
On all four reports that unique Transaction ID is listed for each line, and we use some Excel VLOOKUP functions to pull all coding information, allocation splits, and itemizations onto a single sheet. We then clean up the data (i.e. replace any Undefined Expense Types with a Miscellaneous one, some organization-specific items, and ensuring fraudulent activity is coded correctly), verify the total amount, and send to our accounting software.
The whole process takes me about 2-3 hours or so to get it right, but it gives us the full gamut of transactions within a reporting cycle to the penny. We also use this as a motivation for our employees, to say "If you don't get your report in on time, default coding values will be applied and you'll need to submit a request to have it corrected on the back end if you want your budget info to be accurate."
On average, we have about 5% or so that goes unassigned and that has default coding applied, but we had an aggressive push a year ago or so to get employees' default coding updated, so that reduced a lot of error, even with this 5%.
We decided not to post the CBCP expenses of our Ghost Cards via Concur ... due to the mentioned problems with unassigned/unsubmitted transactions and necessary reconciliation efforts.
We instead post the billed transactions from the invoice feeds of the credit card companies.
Our Concur Travel is configured to submit personnel ID and cost assignment information for every traveller/transaction to the credit card company and they then include it in their invoice feeds, so Finance has enough information to do the posting when they receive the credit card bills.
In the accounting extract from Concur Expense (to SAP FI in our case, via native SAP integration) we then exclude the CBCP expenses, so that they are not posted twice in the end.
This approach works for us. Might not work for other companies though in case they have employees running around with Company-Paid cards and regularly making personal expenses with those by mistake. (our only CBCP cards are the ghost cards used for flight and train bookings. All other expenses are paid by the employees out of their pocket, except for a few IBCP cards in top management).
We have a little effort afterwards though with manual reconciliation and "inter-company settlement" (within the group), because our employees are supposed to enter an "alternative cost assignment" in their expense reports in case their travel costs should not be assigned to their default cost object. For this we built Intelligence reports that show the differences on a monthly basis ... those are then used by Finance to do the manual reconcilation.
Maybe this gives you some new ideas ...
We use a slightly different approach for our CBCP cards involving a transitory account in our G/L.
When we receive the monthly statement information from our bank (download in CSV), we create a posting that credits the full statement amount to the Bank Vendor, then creates indiviudal debit lines for each card transaction into a transitory account. In each of the debit lines we record the individual transaction ID supplied by the bank.
Then, as we process expense claims from Concur, and CBCP card transactions debit the relevant Expense G/L account (based on expense type) and create credit postings in the transitory acccount, recording the transaction ID into the same field. Then it is simple to run an automatic clearing process over the transitory account to group transactions that share the same transaction ID and have a balance of 0, and mark them as cleared.
This method helps us keep our "real" G/L clean, with only approved, cleared expenses being posted, whilst in the mean time allowing us to track the un-reconciled expenses in the transitory account. At the end of each month, our finance team can look at the total in the transitory account and enter a suitable accrual which is then reveresed at the start of the following month.
I hope this helps, happy to provide any additional info if requested.
We would like to follow almost the same process as you have, just without using a transitory account, instead upload individual debits on vendor accounts. Each employee will be created as a vendor in SAP.
The main issue right now is that our Concur consultants are not able to map the <ProcessorTransactionID> from the Master Card feed. The transaction reference ID in Concur is different from the transaction ID we see in the bank report. They were able to map another ID called Acquirer Reference nr to a custom field in Concur, but it is not unique according to Master Card specification and it is too long (23-char long) to use for automatic clearing in SAP. Clearing can only handle up to 20 char long string.
Did you experience similar issues? How did you resolve it?
I'll do my best to explain our process.
We use the SAP FI Native Integration for posting our expense claims from Concur to SAP. This integration places the credit card transaction reference number into the Text (SGTXT) field of the lines posting to our transitory account. I believe the text field is used for the very reason you mention that it can support a larger number of characters.
We then download a CSV file from our bank once a month after the statements have been posted. This CSV file includes the same Transaction reference number that appears in Concur. We then use the information in this CSV file to create a bulk upload to create journals in SAP using SM35.
We then configured the automatic clearing in SAP (OB74) to use the SGTXT field as the criteria for clearing over this transitory account, then setup a nightly scheduled run of F.13 with a variant to run the clearing process.
This makes the process very efficient. Each day as our Expense Processors approve claims form Concur, they are automatically posted into SAP through the native integration, and each night the automatic clearing runs to clear and matched transactions in the transitory account.
Hope this helps,
Thank you for the additional info. So the transaction reference number in your Concur system is identical to the bank's reference number. Great, this is a very important information for us! This should be sorted out between Concur and Bank/Mastercard why those IDs do not match in our case. Unfortunately, it is a major show-stopper for us at the moment. Do you know which technical field is mapped to the reference nr in Concur from the card feed datastructure?
In standard system you are not allowed to add fields that exceed 20 chars to OB74. I guess you had to implement notes 117393, 1078256, 2005540 in order to do that. How many chars are you able to use from SGTXT?
I am very sorry, but I don't know how Concur maps the import file received from the bank - we have multiple card feeds from different providers (MasterCard, VISA, AirPlus) and in all cases it just worked...Concur mapped the transaction reference number and it is the same as we see in the CSV file we download from each provider for matching.
I was also lucky that when I came to start our this automated clearing process, our SAP system had already been enabled to let me select SGTXT in OB74, so I assume those notes you mentioned have been applied to our system, but this is maintained by our SAP Technical team.
Sorry I cannot be more helpful with your questions... I hope you are able to resolve the situation with Concur and the field mapping.
We too are trying to follow the same process as described by Dave but are also facing the same issue where the unique transaction key provided by Concur is longer (37 Characters) than what the SAP Auto clearing program (24 characters) allows. What we found was that only the first 24 characters are considered int he Auto Clear program. This means that if the first 24 characters match and net is zero, it clears.
The problem is, the auto clear program may consider additional items since they first 24 characters of the unique transaction key may not be unique. This would cause some items not to clear when they should.
Wondering if you ever solve this?
Much like Bennington explained. We have setup a corporate card clearing GL account. When posting Concur batches, we debit the expenses and credit the clearing account. When we pay the bill (which we pay in full each month) we generate an invoice that includes the total charges for all employees at the statement date, put it through AP, and debit the clearing account.
We accrue the expenses that are unsubmitted at the end of the period (reversing entry to debit expense and credit clearing account). There is always a difference in the clearing account because of the timing of the statement date and period end. The clearing account makes it much easier to manage the timing difference because there is no way all expenses will be submitted on time.
A BIN Code or payment card number is the card identifier found on payment cards, such as credit cards and debit cards. The random BIN Generator will gives you ten bin code numbers for your using. this helps you to get more information about Bank Identification Number Checker.