I'm late to the game, so my post will be buried. But I'll toss in my 2 cents.
I think, for a company of appropriate size (and I think yours is at least that), that you should have internal development.
The IT department is a service organization within the company, and the dynamics of business never seem to stay static. They're always changing, always in flux. Either internally, through external competitive pressures, or external regulatory and other policy pressures.
Nobody knows your business better than you do.
I've worked on the small dev teams of several companies and organizations like yours, and we were never without work to do. Also, having in house dev simply makes that resource available to your company. It's a sunk cost, they may as well use it for their new programs for marketing, for analysis, etc.
And if something comes up, a problem in the system, an external event, you have staff who's priorities you directly control that you're able to focus on such an event.
A simple example of that was when I was working for a magazine publisher, and they canceled one of their new magazines. So, suddenly, we have this need to print 5000 checks. You may have never printed a check, I can assure you there's all sorts of controls and gates in the system around printing checks, and when your normal routine is to print "dozens" of checks per week, 5000 is "a lot".
We basically had to go in through the "backdoor" of the accounting system to convince it that it had properly printed the 5000 checks. I can say it was with trepidation when I threaded the boxes of checks into our large printer, as this was the moment when all sorts of things can go wrong. Normally, there were done on a smaller printer in Accounting. Maria printed the checks. Always be on Marias good side. She was a very nice lady.
The point being that your contracted help may not have the bandwidth to adapt to your internal emergencies when they happen.
One thing I learned installing accounting systems is that as generic as accounting is, everybody does it, at the same time, everybody does it differently. Off the shelf systems almost always hit that 80-90% of "what we need". It's that remainder that's always the challenge. That part of how you do business vs how the accounting software does business.
And being on the busy end of the outsourced consulting contractor, I know how painful it can be when we're busy, and a customer has an urgent need.
As a developer, I enjoyed working for mid size companies. There's tangible value handing over a new report or point out a new field, or piece of functionality that's there specifically to make Suzy in Shippings job easier.
I watched a lady running the Trial Balance at the end of each day. TB are busy and slow reports (particularly back in the day of slow machines). She'd run the report, print out the 3/4" plus of paper that comes flowing off the printer, grab the last page, tear it off, and dump the rest into the recycle bin. She was after a single number off of the summary page (open balances I think). This process took over a 1/2 hour. You can imagine the delight when I saw her doing this, asked what she was doing, acknowledged that it was a slow process at the end of the day, and came back the next day with a single page report that ran in 10 seconds to do that same thing.
All that said, maintaining institutional knowledge coded into software is REALLY hard. It really hard to not have That Guy that Knows Everything. Not just what's where, not just how things work, but also how things don't work. Why certain fences are put in place that may not be intuitive to someone not well versed in the business. As my friend says, it's always important to understand why a fence was put up, why a process does some "silly" thing, before you go tearing the fences down. And it's really hard to communicate that kind of thing.
But this is a problem intrinsic to computer software and organizations. Whether the folks are in house, or not. Even if folks write up the best documentation in the world, it doesn't mean it gets read, or even found by the person who simply doesn't know what they're looking for.
One place I coded up new pricing incentive plans that were different every year. All sorts of deals, volume discounts, combo offers, and what not (I won't even get into the royalty agreements, oh man). Even by the third time there wasn't really enough commonality to make me go "lets write a generic pricing system that they could configure". But the key thing, is that the orders had to be calculated with regards to the pricing system that was in effect at the time of the order. It's not as if you could toss out the old code each year, oh no. Several years later, the people that even conceived of the pricing model in marketing, may well not even be with the company any longer. But, institutionally, you had to retain that knowledge, particularly in case of challenges or credits to old invoices, or lawsuits, or all sorts of things.
That stuff is just plain hard to deal with. But it's simply the truth of it. And it's hard to get management to pay for it. It's just a friction in the system. But it's also another reason to perhaps keep it closer and within the company.