50 transaction paging limit

Continuing the discussion from Bank reconciliation and exporting more than 50 transactions at a time:

Hi Glenn,
Sorry, but I’m still so frustrated with only being able to view 50 trans at a time.
I’m again paying my suppliers today, and I have to make multiple payments for my biggest supplier, since there are so many invoices. It’s not just that, but I have to separate all my paper records to match the screen, and it just takes so much longer than having all my outstanding invoices on one page. I can’t even check if the amount I want to pay in total matches the supplier’s statement of how much I owe.

We did discuss allowing a 250 limit a while back, and I have persevered and tried to find ways around needing this limit increased, but I can’t.

Currently the system seems to remember that if my last paging selection was 50, it shows me 50 the next time. What about allowing a 250 limit by selection only? I mean, if my paging selection is 250, then is will default back to 50 next time, rather than making this the standard.

Thanks in advance for the consideration.

When reconciling a bank account the system will show 500 transactions on a single page. This is the only scenario in which the page limit is extended beyond 50.

Displaying 250 transactions per page within the invoicing area is not something that we plan to implement at this stage. It will have an adverse effect on performance for all users if the system needs to pull out 100s of transactions per page, per user. Cloud accounting works a bit differently to desktop software in the sense that resources are shared.

How many invoices are your suppliers issuing in a month? You can log 50 payments at a time, which I imagine would be sufficient in most invoicing scenarios? I’ve certainly not come across this problem elsewhere.


I understand the issues you have mentioned on a few occasions before. Indeed, currently a limit of 100 would suffice.

In my industry, every order is for a bespoke product, and so every order gets its own invoice. I can have up to 100 invoices in a good month of business.

We have had this conversation before, and I think I remember saying that in order for me to achieve what I need to achieve I think I put more load on the server by keep flicking back and forth between pages, whereas if they were all on one page I would only need to request the data once.

Giving everyone a 100 row page limit would put huge additional load on our database. Most cloud accounting systems I’ve seen limit to 25 so even at 50 it’s pretty generous. I don’t believe in most use cases that a limit of 50 would present any problem for 95% of our users. As with all potential areas of development in QF I will leave it open for others to comment and add their vote and if there is wider support we can reconsider our options.

1 Like

Firstly, 50 is more than adequate for me but I have a small business with few transactions. However, I have a few thoughts:
Does the backup feature or forthcoming CSV export feature address this need?
Could it be a premium feature to account for additional resources and limit use?
If it had to be selected each time, would that by default reduce any usage of such a limit?
Could the extended limit only be enabled during off-peak hours? Is there such a thing?

I can’t answer the other ones, but the back up feature (which is already in place - take a look at the link below for info), does export everything in a CSV format.

In terms what is displayed within the web application it may be possible to extend the page limit on a per account basis, as you suggest this could be part of a premium add-on. At the moment there’s too many unknowns in terms of performance so we’d need to do proper bench-marking before making any decisions here.

I will refer back to this thread if there’s any change here.


Would you be able to make a change to the number of results displayed in areas such as viewing clients and invoices please? At the moment the upper limit is 50 and something more like 100 or 200 would be ideal for us.



1 Like

Hi @zappdance

I’ve merged your post here to keep the topic in one place.

Please see the post above from @Glenn regarding the limit.

i also understand the server impact, but we are all paying for this service now, and i am so regularly having to merge data exports which takes time, and frustrating.
exporting all purchases to analyse externally,
exporting all orders by customer to analyse problems or customer income

If the default is left to 50, but ability to export all in filter would be fantastic

Hi @jpitsolutions

Have you used the backup tool at all? This would give you a complete export of your account rather than a 50 item limit. There’s more details in a post above from @Parker1090.

Hello in order to bulk pay more than 50 invoices at a time it would be great if you increased the number of transactions a page can display. 50 is not enough when we are bulk entering lots of purchases. Creating multiple transactions makes following the money less obvious.

1 Like

Hi @Gavin_Smith

I’ve merged your post with the existing feature request so we can track the interest here easier.

I agree with gino, it seems that we only need more on occasion, so the default limit could be 50 or less, but with the exception that paid users can access 100 or more.

Again to prevent resource limitations this could then default back to 50.

We have staff expenses that often end up with over 50 invoices. When this is paid we then have to split the payment as we can only bulk tag 50. This makes the system clunky to use.


I too would like to be able to view all clients for each letter of the alphabet on one page, it’s quite anoying and time consuming to only see 50.

1 Like

We often see more than 50 invoices a month from a single supplier. So being able to select or see more than 50 would be useful.

Could it be done on demand similar to applying a payment to more then one invoice in the bank tagging, where more invoices are shown by clicking on “Show more outstanding invoices?” button?

So only 50 would be shown by default. However on clicking a show more button the next 50 are added to the list. I doubt anyone would mind if the next 50 took a while to load after clicking the button.

Hi, I have been exploring the QuickFile Api free service and created a HTTP Client_Search request. I have noticed that there is a limit of 9 records in the body; the body of the response contains only 9 clients records. The Recordset count on the body of the response, named “Client_Search”, shows up many more records present on my QuickFile account. Is there any limit correlated to your database load availability, like you have mentioned above, also in the Quickfile Api service? Is it possible to receive a HTTP response with more records and if yes it is a free service or do you have to pay to customize it? Does Quickfile include scalability in its Api service?

What value are you passing for the ReturnCount parameter?

Thank you for replying so quickly Ian, It was set to 10, I have tried to set it to 500 and it didn’t process the request, could you please guide me through the max limit that I can set now as default and the max limit we could potentially achieve with a paying subscription?

There’s no theoretical limit to the number of records you can retrieve in total - you just have to use a combination of ReturnCount and Offset in multiple calls to retrieve a “page” at a time.

Start off with an initial call with a sensible ReturnCount of say 50. The response will include its own ReturnCount saying how many entries were actually returned in the current page (which may be fewer than you asked for) and RecordsetCount giving the total overall number, from that you can then work out whether you’ve got them all or whether you need to go back and ask for more. To get a second or subsequent page you call again with the same search options but add Offset set to the total number of records you have retrieved so far, keeping a running total of the ReturnCount from successive calls. Once your running total reaches RecordsetCount then you know you’ve got everything.

Remember that you need to use a different submission number (and recalculate the md5 value) for each call - I typically do it by starting with a number representing the current time in milliseconds (System.currentTimeMillis() in java) and add an incrementing suffix for each call; that is guaranteed to be unique as long as you don’t start two sequences of calls at the same moment.