Your approach is absolutely not secure.
The problem is mathematical, not technical. The search space is simply too small. There are only a finite possible number of values for an account number, and all an attacker has to do is try them all. If his output matches your stored value, he learns the account number. The technology choice of hashing with SHA-256 or encrypting with AES makes no difference.
Account numbers are 16 digits, so it looks like an attacker has to test $10^{16}$ possible values. To a specially crafted application running on a massively parallel processor like a graphics card, that's no longer a big number. (Machines capable of executing 348 billion hashes per second are now being built by hobbyists.) But account numbers don't have that much uncertainty. Valid BIN numbers reduce the attackers job by a factor of a hundred thousand. In your case you said you are keeping half the number visible (masking the other half), so the search space drops to $10^{8}$ possible tests. I can also use the Luhn check digit to recover an additional hidden digit, meaning I only have to try $10^{7}$ possible numbers.
And I'm just making a guess here, based on the statement that you're revealing "roughly half" the number. I assume you're revealing the last four digits, because you probably print those on your receipts and don't consider them secret. And I assume you're revealing the first four digits, because they're the Bank Identification Number (BIN). But BINs are actually six assigned digits, and given the first four I can probably determine the next two with a fairly high degree of certainty (there are far less than the 999,999 valid BINs suggested by the range). So knowing 10 digits plus the Luhn algorithm gives me $10^{5}$ uncertain digits. That's only a hundred thousand attempts, and I can spin through that many tests in a second on my PC without even invoking the graphics card!
The secure approach is to use a service to replace the account number with a non-mathematically-derived value, commonly called a token. Inside the secure service is where you would place the encrypted account number and perform your look-ups. An auto-generated sequence number is fine for this. Instead of giving each group the algorithm to look up an account number on their own, you grant them access to the service.
The service would need to be strongly protected against unauthenticated and unauthorized access, with audit logs tracing whoever is using it. If someone wants to run a million tests, at least you have the chance to detect them.
Also see the PCI Guidelines for advice on handling "multi-use tokens" which is this type of use.
