Correct VAT for payments made through the API

[nikolasrh]

Could you have transactions through the API use the account's default VAT setting?

On my iZettle account the VAT setting ("MVA-instilling" in Norwegian) is set to 8%, but every transaction comes in as 0% VAT. This is troublesome because any receipt that is produced by iZettle is simply not eligible and it makes accounting troublesome when paired with transactions with correct VAT.

[mansbernhardt]

VAT is a purchase detail that should be handled on your end. That it is currently listed on our side has historical reasons, and it will most likely go away in the future. The SDK is designed to only handle payments and any purchase/POS related fields are expected to be handled on your end.

[nikolasrh]

Would you mind clarify a bit? Will all VAT attributes be removed from all functionality iZettle provides in the future? The implications this has, as mentioned in my original post, are kinda significant. If you mean only for the iOS API, then I'm not sure where it's "listed" to begin with.

All transactions done through the iOS API show up on both the default iZettle app and iZettle.com. You have functionality on both these platforms which become obselete because the VAT stored is incorrect. Let's assume for a moment that any transactions I do through the iOS API will inherit my iZettle account's default VAT (8%). All of a sudden I could go into the default iZettle app and produce receipts (either by printing or email) that are correct and legal. I could even have the export functionality on iZettle.com show the correct total VAT for my month of transactions.

If transactions through the iOS API didn't show up on either the default app or your website, but somewhere else, this wouldn't be a problem. But as long as it does, and I have no way to set the VAT through the iOS API, or it doesn't use the account's default value, all information YOU store (given that transactions have a VAT attribute) are infact incorrect.

In my case, this makes accounting more troublesome. The process of exporting the transaction history could've been as simple as a button click, but instead all the entries needs to be looked over and changed. Obviously, if all my transactions used the same VAT percentage, it's very easy to find the total, but if I sell one chocolate (through the default app), then I'm done for.

I strongly belive this is a flaw on your end, and can't possibly think of a downside of storing transactions with the default VAT for the account being used.

[mansbernhardt]

The current plan is that we will start to separate between iZettle POS app purchases and SDK/API payments and the latter would not be included in reports, purchase history etc, but listed separately on the iZettle web portal. The question is if we need some intermediate solution until then.

ping @mikaellothman, @TomasPro, @pederstahle

[nikolasrh]

Thank you for the quick reply.

Well, if you intend to make that change, I'm guessing I couldn't use the functionality (mostly receipts) I suggested anyway, so any intermediate solution wouldn't do me any good in the long run.

Do you have any time frame for this change to happen? I'm guessing there will, as you said in the first reply, be no support for VAT or receipts for these transactions and that I would need to store my own?

Could you give me any insight in why you would make this change versus just adding a VAT parameter to the chargeAmount function?

[petermm]

any reconsideration/update on this issue?

not supporting VAT through the API, creates a huge accounting mess, which leads to an even bigger integration/implementation mess.

having a defaultVAT: true, or even specificVATpercent: 25 - would make a huge difference.

[TomasPro]

Hi Peter,

our view has not been reconsidered and I foresee no change to it in the near term.

Our SDK serves the primary purpose of enabling payment functionality to third party point-of-sale systems. In other words, the function of our SDK is to enable Payment (=card processing) for Purchases (= recorded info about Products, VAT information etc) created in your App.

Payment: we provide payment processing functionalities plus hardware and all legal & fraud prevention aspects surrounding it (such as running KYC procedures, fraud monitoring etc.). Important aspect of processing card payments is payment receipt capabilities - cardholders having the right to receive a proof of payment getting processed. Such receipt must contain information such as AID, TVR & other details that you receive over our API. Alternatively, you can obtain payment receipt via our portal where you can also see the record of all Payments performed using our SDK.

Purchase: What you are requesting is functionality related to handling VAT. Handling VAT is subject to a range of different rules different per country or product type (e.g. in many, if not most, countries VAT receipt without Product Description is not a valid receipt). If our SDK was to correctly handle VAT we would need to own/have knowledge of product(s) characteristics sold - for our own iOS App we have that, for our Payment SDK we don't. Enabling some form of limited VAT handling via our SDK would inevitably create situations where our systems present incorrect tax related information.

We understand the implications that the split between Payments and Purchases might have further down on your reporting or accounting but in many ways that is a consequence of the 'design' that we chose for our SDK.