Receipt Bank and Sage 50

Hi,

My company - Receipt Bank - will shortly be unveiling an integration with Sage 50. We are seeking feedback on what our solution should, and should not, do and are looking for firms who would like to be part of the beta testing of this integration.

Receipt Bank offers accountants and bookkeepers a logistics solution that allows them to:

  1. efficiently gather together clients' receipts and invoices
  2. scan these documents and safely store the scanned copies
  3. extract the key data
  4. publish the key data to where-ever it needs to go

In order to further our improve our ability to achieve (4) we have developed the software to publish data into Sage 50.

Receipt Bank is able to extract a range of data from receipts and invoices including:

  • currency
  • total amount
  • VAT
  • name of supplier
  • date
  • due date (if appropriate)
  • invoice date (if appropriate)
  • etc.

This data will then be sent straight into Sage 50 for your clients so that you, or your team, no longer have to process that Tesco bag of receipts!

Receipt Bank is a cloud solution (so that our users can access us where-ever they are) but our Sage integration will involve desktop software the will link directly with your copy of Sage 50.

If you have any feedback that could help us to improve this integration please contribute to this thread.

If you would like to participate in the beta testing of this integration please contact us at info@receipt-bank.com.

Regards,

Michael

Comments
Witch-Queen's picture

Re: Receipt Bank and Sage 50

Witch-Queen | | Permalink

I can't honestly see how this will work, and especially how this is suppost to save time.

I wouldn't trust the software to know the difference between an order date and a tax point date and how does it know which number on the document is the invoice number? I've had imput clerks not know the difference, so how will a piece of seftware? And how will it determine the Nominal Code to be used? How does it know the difference between a sales invoice and a purchase?

I cannot see this saving any time, in fact it will take longer to process the data. 

OK so the client wastes his time scanning the Receipts/Invoices into the software, instead on me imputting them into Sage. Scanning will take a lot longer that it would take me to manually imput. Then at year end I will still need to go through every single document, find the matching transaction in Sage and correct it.

No thanks! I'll stick to the traditional way.

Unless you can prove me wrong?

-- Witch-Queen

Michael Wood's picture

We'd be happy to demonstrate!

Michael Wood | | Permalink

Hi,

Thank you for the feedback!

To respond it's probably best to go over some of the benefits that our clients receive from using Receipt Bank: the first is that we safely and securely store the scanned receipts and invoices online. As HMRC accept scans as supporting evidence, this is a big benefit in a time when HMRC are threatening ever more inspections! The second is that by providing you with a 24/7 platform that enables clients to submit receipts and invoices whenever they want (by email, by freepost, by iPhone, etc), it reduces the 'wastage' that clients currently incur through lost receipts, etc. The third is the time saving...

You are absolutely right that software today can struggle to distinguish which number on the piece of paper will be the invoice number. Receipt Bank uses both software and manpower to ensure that this isn't an issue.

As part of our integrations, Receipt Bank 'reads' the nominal codes and the list of suppliers from (in this case) Sage 50 so that we can allocate the transactions correctly. Furthermore Receipt Bank has the ability for you to set 'rules' (i.e. any receipt from Starbucks = Subsistence) so that you can be even more efficient.

We are mainly used for Accounts Payable but there are ways of using Receipt Bank for Accounts Receivable. The system can easily be set up to ensure that these two document types are treated, and held, seperately.

In our experience every firm, and individual, is different. And using unique processes. This makes it very difficult for me to say whether we can help you to save time or how much time you would save. I can say that our clients save time in the prompting and collecting of documents from clients, and save time in the sorting and data entry of these transactions. Clients also save time (they don't have to do the scanning - we can do that).

The aim of our integration with Sage 50 is to reduce the time you need to spend on each client. But we will only find out how successful we are at this when the beta test is complete!

If you would like to find out more, or if you have any further questions, please don't hestiate to contact us on 020 8144 0739.

Regards,

Michael

www.receipt-bank.com

 

 

Hmmmmmm

ghewitt | | Permalink

Witchy-queen has some good points that cannot be ignored and I look forward to reading your reply.

My own thoughts...

I cannot see that this would be able to cope with all the various types of invoices that we get. Some are handwritten on a piece of cheap spiral notepaper, others have very small letters and numbers and a lot of them; so much so that I have trouble scanning them with my eyes to try and find which number is the invoice number and not the processing number, document number or delivery number. I can only see this working if all invoices were standard. Talking about a 'Tesco carrier bag' - what about those Tesco receipts? For petrol or goods in store, they are covered in numbers.

How will it cope with the nominal selection? How would it know, for instance, that a purchase by and for a director goes into the loan account and the VAT is set to T9 not T1.

It sounds a good idea in theory - and I am all in favour of anything that takes away the tedium and makes for a more efficient office - can you tell us how it stood up in practice when you tested it?

I have issues with cloud computing; it is all very whizzy and all that but is not infallible - I think the recent Amazon? crash showed that up; and this would mean an internet connection, obviously, but how much bandwidth would you use sending the generated files? I don't like the idea of trusting my data to the net generally - such as online backups etc; call me a ludite if you will but I like to see my backup drives whirring away and flashing their little acitvity lights saying all is well.

 

 

Michael Wood's picture

Would you like to test it?

Michael Wood | | Permalink

Hi,

Thanks for your comments.

We do get a huge range of invoices and receipts! As you say: bits of paper, software generated invoices, Tesco receipts, etc. and we deal with foreign currencies! We have been able to create a process that works. There are still occasional items that we struggle with but these are very rare in the thousands of items that pass through us every month.

Selecting the correct nominal code is the hardest part of the data extraction process for us as we can never know the client as well as you do. However what we can do is reduce the amount of time you need to spend on each batch from each client: our 'rules' technology enables us to learn a client so that if something is incorrectly allocated the first time then it can be corrected and remain correct for all following months, years, etc.

With regard to cloud computing, you are absolutely right that it's not infallible. However I think that although the issues, such as the Amazon outage, are very high profile they not as frequent as many people fear. For example most people are comfortable with their 'cloud' emails at Gmail, Hotmail, Yahoo, etc.

At Receipt Bank, we believe in data portability which means that you can download your, and your clients', data whenever you wish. I know that some of our partner firms take advantage of our pdf export to send their clients a pdf of all their receipts and invoice once a quarter/year so that the client also has a copy.

Would you be interested to see an online demo of the service? If so please feel free to contact us.

Regards,

Michael

Add comment
Log in or register to post comments