Bill/Transaction/Actual mismatch
4K_Tech
Member Posts: 3
I have a bill in Wave of 131.40. Recently the payment for that bill imported, again 131.40. When in Accounting/Transactions and go to assign that payment to a bill, the amount that comes up is 131.39. If I assign it, of course the system shows an overpayment of a penny.
Tagged:
0
Comments
Hi, @4K_Tech.
Can you show me a screenshot of that bill? I'd love to try and find out where that rounding error is coming from.
Hi @4k_Tech.
I did some digging, and our engineers are aware of the issue. They're working on a solution right now. You can just enter the payment of $131.40 for the bill. The Accounts Payable entry for that bill will be off by a cent, but that'll be fixed once the issue is resolved.
If you want, you can add a line item for rounding adjustment in the bill, but you might have to remove it later down the line.
Cool. Thanks.
Happy to help!
Hi, I just noticed this same discrepancy in my accounting. Was this issue resolved and is there a work-around?
I never heard back so I don't know what if anything was changed. The issue cleared up for me when 2019 started. The issue occurred most often when charging for mileage. In 2018, mileage was ??.5 cents per mile. The 1/2 penny introduced a lot of opportunity for rounding discrepancies I am guessing. With 2019 being a solid number for mileage, I haven't seen it re-occur...
I just did corrective entries in accounting as needed so the bills matched up with payments. Not correct; kind of messy looking; but only talking pennies.
Kris
Thanks @4K_Tech! The issue is still occurring for me when posting a bill payment from Accounting/Transactions and has occurred as recently as May 2019. @Alexia, do you have any additional information regarding this rounding issue? I am also noticing when I created the bill, the total is $2591.88, but when I view a summary of the bill in the Purchases by Vendor report, the credit total is $2591.87.
@PaulC, can you please assist with the following error in this discussion thread?
Hey @MarquezW
If you're experiencing the issue that I think it is, then this something we're still working on unfortunately. When it comes to tax rounding at Wave, this process is completed on a line-item level. What this means is that each product line will calculate the tax, round to 2 decimal places, then do the next product line. At the end, it will add up all the line item tax calculations and plug that in as a total tax in your invoice. Unfortunately, there is no way around that in our software at this time.
As a potential temporary workaround, feel free to add/discount item for $0.01 to charge the right amount and mark it as an adjustment entry for the time being. If this doesn't sound like the right, can you let me know if you're applying taxes to your bills? If you're comfortable with doing so, feel free to shoot me a DM with your Wave email and I can take a look as a collaborator!
Hi @Samd, this discrepancy is not occurring with tax calculation. The bill contains one line items and it's a simple Quantity * Price calculation of 79.75 * 32.5 USD with no tax. The bill itself shows the correct amount of $2591.88, but when I go to assign the payment to this bill in Account/Transactions, the bill amount shows as $2591.87 resulting in a $0.01 over-payment. I am more than willing to assign you as a collaborator if you are not able to duplicate the issue in your lab.
@Samd , any update?
Hi @MarquezW not sure if you DM'd @Samd in regards to this, but if not, I'm happy to explain this further.
As Sam explained, this seems to be an issue caused by rounding. It sounds as though a tax was applied to the value single line item. As Sam explained the behaviour when there is multiple line items, a similar process occurs when there is only one, in which Wave will round to the second decimal place. I totally acknowledge that in many cases, business will opt to always round up when billing customers, however in order to never overcharge your customers, we have made the decision to stick with conventional rules.
It sounds as though in applying the payment, you will likely continue to have selected invoices overpaid or underpaid by 0.01. If this is the case, after receiving the payment outside of Wave, I would recommend creating a product titled "rounding adjustment" and applying this to your invoice after receiving the payment, so that you can match the amount on the invoice, to the amount collected. This process would work in the case where you receive less or more from a customer and ensure that the bill/invoice is marked as paid, rather than overdue.
@JordanFromWave, thanks for your response. I question why Wave doesn't apply the conventional rules of rounding across the board. The bill itself shows the correct amount of $2591.88 which is rounded up. The payment applied is $2591.88 as well, and after applied to the bill, the bill has a zero balance. But, it's the reporting of the bills where the rounding rules aren't applied. When you look at the summary of the bill in the 'Purchases by Vendor' report, the credit summary shows a total of $2591.87, even though when you open the bill itself, you see the total for that bill and the amount paid was $2591.88 and a zero balance. Because of this, the report shows a $0.01 overpayment for that bill even though the bill itself shows a zero balance. As such, a "rounding adjustment" against the bill/invoice won't work because it's as expected and a zero balance.
@MarquezW. I do feel as though this might be better handled via support ticket, so I've gone ahead and sent you an email so that we can further discuss/investigate what might be going on with your account here. Please respond to the email once you get a chance.
@JamieD, I have sent screen shots to the support distro as requested that hopefully better explains the issue. Thanks!
I am getting exactly the same error please can you advise the status of the support ticket as it is now my Year End so I need to know how to handle the discrepancies
@DavidH, I received the following response from Wave Support: "After review the screenshots, this is actually a bit of a known bug that is currently being investigated by our accounting team. It might take a bit of time to fix since it's a bit of a lower priority for us, but when we have more information I will be happy to let you know."