willwoodThe thing that will be important to get right is that purchasing customers will need an invoice or receipt with the following on for each purchase:
- My name, address, VAT number
- Customer's name and address
- A clear breakdown of gross and net costs
- Transaction details (like the date, ID, IP number)
I don't know whether this is something that can be setup as a custom template sent to the customer or provided as a separate email? 2Checkout claim to send this out already when I asked them, but a copy I saw from a customer was missing much of this.
You can already customize your E-junkie-generated thank-you pages and/or thank-you email messages to provide most of that information either directly or using template tags to insert order-specific data:
E.g., this help page offers some tips to format your E-junkie-generated thank-you page as an invoice or bill of sale:
We are planning to add new template tags to insert things such as VAT totals, rates, and locations used to determine those rates. We have not seen any official documentation stating that the buyer must be shown a per-item breakdown of exact VAT rates/amounts or net prices excl. VAT at any point -- indeed, this poses problems with compound rounding errors -- as long as they are at least informed that the seller is collecting VAT and shown their gross cost incl. VAT, thereby excusing the buyer from having to render VAT themselves. If you think a more detailed VAT breakdown is necessary, please provide a link to official documentation explicitly stating so.
We also have not seen any official documentation stating that transaction records must solely be kept on servers located within the EU; if any such requirement exists, again please provide a link to official documentation explicitly stating so. E.g., amateur layman's interpretations suggesting so may well have misinterpreted regulations which might not require EU storage exclusively but, rather, may merely require an EU-hosted backup copy or may apply only to data that happens to be stored on EU servers, such as an export of log data that you may retain for your own records.
takethreeWould it be possible to give us the option of not including the shipping address part of the checkout and have one less possibility for the two items of proof of location? For example, if we only use Paypal, it could compare the GeoIP and the Paypal billing address and hope that they match. And if not then we still get the "possible fraud" notification you mention above.
We might consider that -- i.e., retaining current behavior where collection of a Shipping address would remain dependent on Shipping/Buyer's Address being checked in product settings -- if we could possibly collect other items of information to substantiate the buyer's place of supply. Collecting only two items (GeoIP and Billing/Residence country) to satisfy a requirement for a two-way match seems risky, and three is ideal, as that precludes any possibility of conflicting two-way matches.
At purplepixi's link (
), HMRC mistakenly seems to think "the country code of the customerâ€™s bank or registered credit card" A) is somehow knowable to us independently of whatever Billing address the buyer provides, and B) could ever possibly fail to match the Billing address country specified by the buyer.
Payment gateways simply don't transmit country codes back to us in their charge authorization responses, nor is there any need to, as the Billing address (including country code) the buyer provides, which we transmit to the gateway for card authorization, MUST match the address registered to their card account in order to approve the charge in the first place. HMRC's suggested two-step approach here seems completely ignorant of this inherent failsafe in residence-location verification and is apparently attempting to reinvent that particular wheel.
SeanMcDoes the new VAT tickbox in the Beta Admin panel do this now? I know the report currently gives an IP, but not a country. Just wondering how far along we are with this, as I may end up just pulling everything as the overhead in time just doesn't justify the grief.
Our new Admin Beta is just a drop-in replacement for our Flash admin, so the VAT settings in both Admin versions work the same. The new VAT calculation and recordkeeping behavior we're planning will be prepared in advance and go into effect as of Jan. 1, 2015. We'd notify in advance any sellers who have VAT enabled about the change and any actions we'd recommend to accommodate the change.