Invoice number complying with EU & Spanish law

Hi,

I'm a new business, and I have been told that in order to comply with Spanish (and European) law, all invoices issued need to have following numbers, without any gap.
But the booking code generated by Checkfront contains random letters and the date (YYYYMMDD), so this can not be used as an invoice number...

I'm wondering how other businesses deal with creating proper invoices with correct number?
any advice would greatly help!
Thank you!!!

Comments

  • Hi Dedric, 

    Thanks for your post! At this time, the ability to issue invoices with sequential (following) numbers without any gaps would be considered a feature improvement. The request is on our Product team’s radar, and others have requested this feature as well, so I’ll add you to the list.

    I’d like to hear more about your exact business requirements in Spain, so I’ll send you a quick note in just a moment. Please keep your eye out for an email from support@checkfront.com. Thanks and talk to you soon! 

    Laura
    Technical Support Manager, Checkfront 
  • Hi Laura

    We have just gone live with Checkfront and use the Xero integration.  The invoice created in Xero from Checkfront uses the 'Booking ID' in Checkfront as the invoice number in Xero.  This is a random number made up of 4 letters and then the date.

    UK tax law requires invoice numbers to be sequential - "Unique invoice number that follows on from the last invoice"

    https://www.gov.uk/vat-record-keeping/vat-invoices

    Can consideration please be given to re structuring Checkfront so that if the Booking ID is to be used as the Invoice number in the Xero integration, the Booking ID constitutes as sequential number, following on from the last Booking ID.  

    e.g. CH-0000250, CH-0000251, CH-0000252 etc

    Or, some other mechanism which produces sequential invoice numbers in Xero via the integration

    I very much hope this can be achieved pleased

    Many thanks

    Glenn  
  • and it's not just UK or Spain. It's EU-wide:
    https://ec.europa.eu/taxation_customs/business/vat/eu-vat-rules-topic/vat-invoicing-rules_en#what_information

    What information must an invoice contain?
    Full VAT invoices
    Information required in all cases

    Date of issue
    Unique sequential number identifying the invoice
    Customer’s VAT identification number (if the customer is liable for the tax on the transaction)
    Supplier’s full name & address
    Customer’s full name & address
    Description of quantity & type of goods supplied or type & extent of services rendered
    Date of transaction or payment (if different from invoice date)
    VAT rate applied
    VAT amount payable
    Breakdown of VAT amount payable by VAT rate or exemption
    Unit price of goods or services – exclusive of tax, discounts or rebates (unless included in the unit pri
  • We are also in the same situation. Our tax and invoice requirements in the UK are that BY LAW, we must have sequential numbers on the booking ID/invoice numbers. This is now urgent - the answers from Checkfront above are from Aug 2018, and then....... silence. Please let us know about this improvement asap!
  • @GoAdventures

    I recently followed up directly with Checkfront Support on this matter and had this response:

    "At this time, Sequential Invoicing is considered a Feature Improvement. 

    A few recommendations that customers have brought forward are filtering the Booking Index by either created or start date (depending on your needs) and exporting to a spreadsheet or accounting application from there for additional sorting is the best way to manage."

    So, I replied with this:

    Thank you for your reply.  I have a number of questions by way of follow up please.

    "At this time, Sequential Invoicing is considered a Feature Improvement" 

    Does this mean it is not on any development plan?

    A few recommendations that customers have brought forward are filtering the Booking Index by either created or start date (depending on your needs) and exporting to a spreadsheet or accounting application from there for additional sorting is the best way to manage.  

    I'm really not sure why you may think the above would suit our purpose as this defeats the object of having integration and sync with Xero, which was one of the key features for deploying Checkfront in the first place!

    Our whole Company ethos is systems integration and we deploy a number of Cloud solutions based on the important requirement of integration with Xero.  Checkfront is the only product which causes the issue of not numbering sequentially.

    I have mentioned that European tax law requires sequential invoicing.  Currently, Checkfront creates an invoice in Xero and uses the Checkfront booking reference as the invoice number in Xero.  Whilst this reference uses a date in part of its structure, essentially the booking reference structure you use has no sequence to it and cannot be sorted in any kind of order!  Naturally, this lack of order is reflected in the subsequent invoices created in Xero.  I really do not see any importance in attempting to utilise a date format in the reference number especially when you then combine it with random letters which takes away any kind of ability to sort in any kind of useful order.  

    I hope you can appreciate this is a major pain point and I really don't know why Checkfront continues with this random strategy which subsequently undermines the Xero integration feature.

    Looking at two of our other systems, they integrate with Xero as follows:

    1. MembershipWorks (Membership & Events)


    This system manages our membership and events requirements.  It will take payment for transactions via our website.  The sync with Xero will create invoices in Xero and use the next available invoice number in Xero for that invoice number. 

    2. Dear Systems (Inventory)


    We use 'Dear' to purchase and manage our comprehensive wine inventory and cellar.  It has a sophisticated 2 way sync with Xero including sync of transaction documents from Dear to Xero transactions.

    It uses its own sequential invoice numbering system created in Dear by the admin.  This is transmitted to Xero and, whilst not falling in line with the internal Xero invoice numbering, is still perfectly acceptable as all resulting invoices in Xero are sequential.  They are also prefixed with 'WN-' which identifies them as coming from Dear.

    So, I hope you realise that Checkfront is dropping somewhat behind the curve by continuing down the current track and not appearing to deal with this issue as a matter of importance when it is directly affected by tax law.  IMO, there would be two solutions:
    • Change the referencing numbering in Checkfront to something which is sequential and can be used for the Xero invoice number
    • Create an additional transaction/reference number in Checkfront which is sequential and use that to create the invoice in Xero
    As the systems manager for the Vintners' Company, my role is to continually monitor the systems we deploy and to look for improvements.  We will move to better systems when they prove more suitable to the required task and I'm sure you are aware that others are developing functionality all the time in order to complete.  Checkfront's stance on this point is therefore a matter of concern for me.  

    I am also sure that you realise that integration with cloud based finance systems is becoming more and more the requirement so I would feel it is in your interest to make your product as effective and thereby as attractive as possible. 

    I would welcome your response and additional thoughts on this or perhaps you may wish to direct my comments to someone else in Checkfront who may be able to provide me with a more reassuring response and clearer idea of where Checkfront is heading in this area.
  • @glennroberts: thank you for sharing.

    The more time I spend on this community forum and read about customer's problems, and how Checkfront pretty much always reply (ie At this time, this would be considered a feature improvement. I've added your name to an existing feature request…."), the more I am convinced that CheckFront's strategy is to prioritise their US & Canada based customers.

    For the rest of us, we will have to find our own work around whenever CheckFront is not "natively" suitable.

    I can't see any evidence that CheckFront will make specific efforts to accommodate EU or worldwide businesses (unless of course it serves US & Canadian businesses too!).

    Even more worrying, is how long it takes for any [feature] request to become a reality. And not just on "small" features; even important ones seem to take for ever before they are addressed. (just have a look on this forum, and you'll be amazed with how old some threads are! and the associated issues still remaining unsolved).

    And the fact Checkfront refuses to provide us with a clear roadmap of their upcoming developments only confirms my fears…


    I would love to be proven wrong!!

    PS: I still believe CheckFront, as a booking system, as a lot to offer; but I can't recommend it to any business because of the lack of Customer service provided.
  • Feature requests from US & Canada-based customers are generally ignored as well.
  • Hi all, 

    Thanks again for your continued engagement with our community forums. I've shared your feedback with our Product team, and we'll be replying back next week with an update. 

    Best,
    Laura
    Director of Technical Support
    Checkfront 
  • Hi @Laura_Checkfront,

    "we'll be replying back next week with an update."

    dare I hope that the issue will be addressed (and solved) ?! That would be fantastic!
  • StephanieStephanie Checkfront
    Hi all,
    In reviewing this request, it does require more than just making the invoice ID numeric, as we’d also need to prevent the deletion of bookings/pre-bookings in the sequence. This is on our Product team's radar, and something we currently hope to address in the upcoming quarter. If this is a feature you are interested in, please advise our Support team of your account information so that we may track you to the feature request and provide a future update.
This discussion has been closed.