Jun 29, 2017

Batch Summary Report


We had a few requests for a report that shows the daily batch totals for a given range. This will help customers reconcile the daily batch from the POS to what has been deposited in the bank. It would just consist if the date and a credit card batch total for each day in the range set. Thanks!

Jun 29, 2017

Hello Matt,

If you're using EMV we have that report already. For the other legacy swipers -- the processors may not provide an API for us to get batch total. The batching may be automated on their backend and we cannot get at it.

Jun 29, 2017Edited: Jun 29, 2017

Hi Davis,


The EMV batch report is not returning near the numbers we see in the monthly cc sales totals. For May we see a difference of $70,000 between the total cc sales and EMV batch history. I was told by support that the EMV history only reports on the EMV transactions, but that does not seem right either as it also skips several days, even weeks, of batches. Would be very unlikely that we did not take a single EMV card for a whole day or even week for that matter. Are we missing something there?


Is there a way to compile a report that at least would show by day what the batch total being sent from the POS is? No real need to communicate twitch the processor, just have the POS return what the total for the day was.

Jun 29, 2017

Hi Matt,


Let me try to explain how those batch reports work; it may help improve the process and explain things better.


I'm not sure if you're using a mixture of PAX EMV hardware and legacy USB swipers. If you are, the batch history reports are only applicable for the PAX hardware. As indicated prior, I don't have access to batch execution for legacy swipe processors, which is why we currently don't provide reporting on that.


For the PAX hardware, they are set to auto batch at a set time. We traditionally set this time one hour in advance of your Auto End Of Day time. When a PAX terminal reaches that time of day, it attempts to close the batch for whatever transactions it currently has in its memory. If it fails, it will continue to re-try for up to an hour every three minutes. Once the batch either completes successfully (or if it failed), the PAX will hold the results of the last batch attempt in its memory. This is why we set the Auto End Of Day time for an hour later. When Auto End Of Day runs, it will close out orders, clock out employees, and run final POS reports. The last thing it does is broadcast a notification from the cloud back to your stations. One of the messages it broadcasts is a request to gather the batch reports from all of your available PAX terminals.


One of your stations will pick up that request and reach out to all of the PAX terminals on your LAN, and gather the results (either success or failure of the last batch report it ran -- or it will time out if it fails to get a response from the PAX terminal). These aggregate results are then stored in our database, and migrated over to our data warehouse where they will then show up in the report.


There are a few possible outcomes from querying the PAX terminals for the last batch report. Bear one thing in mind, though: the PAX terminal only stores the last batch result. We cannot query it for history beyond the last day's result, so if a day is missed where we did not collect the report, and a new day is started with a new batch number, we have no ability to go back and get the prior day's report.


Here's what can happen / what can go wrong / and ways you can mitigate against problems:


1. Querying the terminal returns a successful batch result that contains # transactions and total dollar amount for that batch.

2. Querying the terminal returns a failed batch result with an error code. This usually indicates something that should be addressed and probably should have support look into it to see if we can force close the batch so the batch won't bleed into the next day. One error we see sometimes returned is that someone left a card in the terminal. For whatever reason, if this happens, it won't return us the report until the card is removed. But this does not indicate in and of itself that batch wasn't successfully closed -- at this point we just don't know.

3. Querying the terminal returns an error that indicates the station timed out waiting for a response. This typically means the terminal was offline or unreachable. We see this happen not too infrequently because people turn off network equipment or inadvertently unplug things.

4. Querying the terminal returns a successful batch result, but the terminal has not run any transactions since the previous day. We can tell it is a duplicate result by comparing timestamp, batch#, and the count/amount. In this case, we don't store the duplicate. This can be a bit deceiving as it can make it difficult to tell what happened: a) did the batch somehow not close or b) was the terminal just not used that day. This might be something I can improve upon to add a definitive record that will indicate in the reporting that the report was a duplicate.


If the station receives the notification to run the batch reports after EOD, then it will reach out to all PAX terminals and it should result in one of those four possibilities. Another possibility, however, is that the notification to run the reports was somehow lost/missed. We see this happen, again, because people turn equipment off / unplug things inadvertently, or possibly Windows Update ran and rebooted the station, or possibly the stations go into low power mode and go to sleep, etc. There are a number of reasons why this can happen. Without being familiar with your specific environment, it is tough to say, but if you can -- please try to ensure that all POS stations and PAX terminals stay online/awake and connected to the network 24/7 -- especially during those hours around your Auto EOD time.


Here are some mitigation strategies when things go wrong:


For #2 above, if you have a failed batch with an error code for any of your terminals (aside from the error indicating to NEED REMOVE CARD FIRST), you should contact support and ask for assistance in closing the batch. Here's an example of that error about the card:

If you get this error, you can ensure all cards are physically removed, and you can re-execute the batch report query. This can be done both from the FOH and the BOH. On the FOH, the command is under Show Commands => Batch History Reports. There is a button in the bottom left called Query Terminals.

If you push this, the station will re-query the PAX terminals for whatever their last history report was and update. Take note, that you can push this button at any time to try to get the latest information to ensure you have all the reports.


You can also run this from the BOH under Payment Terminals:

For #3 above, we see this not too infrequently, unfortunately. Here's an example of this, where we tried to query the PAX terminal several times, but it did not respond, until eventually someone probably ran the Query Terminals manually the next morning at 7:26 AM and was able to pull the batch report.

If I had to guess here, I'd guess that the equipment is going into low-power mode / sleep / or something is getting unplugged by the cleaning crew possibly. Bear in mind, again, try to keep this equipment plugged in and connected 24/7 to avoid this. The only other mitigation around this is to re-run Query Terminals manually when you notice this failure. Do note, however, that eventually, we were able to pull the report from the terminal, and it had closed the batch successfully for that day.


For #4 above, this one is tougher for you to diagnose. I will try to add something that will show up in the reporting to indicate that the report was at least run, but was a duplicate (indicating no transactions were run on that terminal for the day).


Finally, reconciliation can be tough to do if you aren't batching every single day successfully (e.g. if somehow your batch from one day bleeds into the next). The POS runs all its reports on a daily cycle. Thus, the Credit Card Transaction Report indicates a list of all transactions captured for that fiscal business day, but if your batch bleeds through multiple days, this will be tougher to reconcile. When the POS captured the transaction, and when it batched are two separate events.


We've had multiple requests from merchants to help reconcile -- and we've dug into them -- and while we've found a few minor issues that have since been fixed, we have been able to reconcile. The problem is that it is a very time consuming process especially if you have a lot of failures like in the above screenshots. If you understand some of the details noted above, and ways you can improve your own environment or work around an intermittent failure like noted above, reconciliation will become easier.


One other point, we do have alerts available in the reporting site you can setup which should trigger an email if a failed batch is detected. Unfortunately, if a batch report doesn't run at all b/c possibly the station(s) / equipment were offline -- we don't have a good way to notify you without generating a false positive (maybe your restaurant was closed for the day). We can only report if we detect there was an error.

New Posts
  • Can you create a deposit summary report? I want a report that just shows only the deposits for the day, cash, credit cards, and online credit cards. The only numbers that will hit my bank so my office workers know what to enter into our accounting software. Phil Sobeck Chicken Shack
  • We have 20+ stores and need to be able to process reports more efficiently. For example, I need to be able to get gross sales and net sales for all stores and all companies for a specified period. The dashboards are great, but we need to analyze each store individually and it is very time consuming. Store performance report is the closest thing to what I need, except I need it for individual days. If I need to analyze 30 days, I need to pull the report 30X for each company. Attached is one example of the data I need.
  • What is the ETA on this?
Copyright © 2017 EmaginePOS | Privacy Policy
Proud Member of the Michigan Restaurant Association