First thing, looking at the SELECT operator in your execution plan, you have a timeout. This means that the optimizer gave up on attempting to find a good enough plan for your query. This generally leads to poor performance. It's caused by overly complex queries that the optimizer can't process fast enough. So, before we look to anything else, our first problem is that this plan is unstable and could change over time.

You're joining between a table, Chart_Of_Accounts, and a view, VIEW_GENERALLEDGER. I suspect that we're looking at problems within the view. The optimizer will take the view and attempt to simplify it, eliminating tables and joins that are not needed to satisfy the query you're running. Your view hits 15 different objects, including two other views (nesting views is ALWAYS a problem), further adding to the complexity of this query. But if we look at the execution plan, it's only hitting eleven objects. Clearly, you can simplify this query best by eliminating these views and simply write the query to retrieve the information you need. SQL Server just doesn't lend itself to code reuse. It's not a programming language.

Finally, the SplitIDs function is not costing 0% as suggested by this execution plan. It can be replaced by using a tally table. If you do a search on tally table and the words 'Jeff Moden' here on SSC you can find a good replacement.

I didn't bother looking into whether or not you have good indexes in place because we need to get to a stable plan first. Rewrite the query to get rid of the views. Then you can worry about indexes & statistics and all the rest.