If I understand correctly, you have one index on (acct_id) and one index on (order_date)?
Having an index on (acct_id, order_date) could help some by reducing the number of pages that had to be read into cache only to be eliminated because they didn't contain the data needed by the query. This combination also seems to be a good candidate for the clustered index.
Are the columns used in the report a relatively small part of the total contents of the full rows in the tables (and ideally well under 600 bytes total length)? If so, creating an index on all the columns used in the report would allow the report to get those values using a "covered index scan" of the leaf level of the index and the data pages (with all those unneeded values from other columns) wouldn't need to be read into cache at all.
Faster disks would help.
More data cache could help.
If the table is too large to bind to a named cache, but you can use the coverered index approach and that index is not too large to bind to a named cache, the combination should work very well
It sounds like there is nighttime processing that ages the data from these tables out of cache.
You can prime the cache by running a query that reads in the most likely (I'd guess more recent would tend to be looked at more often) of the data from the tables just a little before start of business processing.
Running update statistics will only help if the distribution of data is changing, and then only if the out-of-date statistics are causing ASE to start chosing worse query plans (table scanning, etc).
The distribution will be changing on the order_date as more recent orders are entered, and you should consider using the "out of range" option for update statistics on it.