I've had to employ a similar workaround. I work in IT, and our Finance team needs to be able to do a revenue flash on Business Day 1 of the new period, which means all of the end of month deferral processing needs to be completed by the time users come in at 8:00 AM. Since implementing Subscription Billing, I've been starting at midnight on the last day of the month to begin chunking the data up into ~50k records per job. Our offshore team takes over while I sleep, then I resume postings until completed. Other points I would add:The Recognition Batch Processing job needs to be multithreaded. It is crazy that the job is single-threaded when there are hundreds of thousands of records created in a single commit.The job needs error handling. It does not make sense for a >50k line journal to be rolled back because a single transaction had a suspended financial dimension. Why doesn't this job utilize the standard journal posting functionality that allows moving lines with errors into a separate journal?There should be a line limit for the journals created by the job. If processing 100k+ lines, much of the time is going to be spent on posting validation. This ties back to #2 where I would rather see three 20k line journals post successfully before the job failed due to a data issue than none of the 100k lines post at all.