The wrong way
It would be tempting to tell you to put each mapping in a database table and query by providing all the relevant fields. This would however miss the fact that rules may be based on partial matching, and that when several matching rules are found, the more specific should apply:
Input data: Output Explanations on rules
Firm Category Sub-Category Code
B b1 sc2 c3 ACCT3 (R2,R3 match but R3 is the most specific)
B b1 sc3 c3 ACCT4 (R2,R3,R4 matches but R4 is the most specific)
B b2 sc3 c3 ACCT2 (only R2 matches, for B)
Solution 1: sophisticated matching algorithm for each mapping
Of course you could elaborate on your mapping table by adding a rule precedence value and generate a more complex query that would find all candidates and take the one with the highest precedence.
This is error prone (comlex query generation, risk of unexpeted rules being selected, need for defining precedence manueally). In addition, it might lead to a lot of expensive queries.
Solution 2: matching algorithm using successive mappings
Another approach could be to determine a set of mapping table, and let your rule engine iterate through successive conditions, stoping whenever a matching rule is found:
Firm Category Sub-Category Code Acct = InternalCode( Enriched )
A a1 sc1 c1 acc1 = ACCT1
B b1 sc3 c3 acc4 = ACCT4
Firm Category = InternalCode( Enriched )
B b1 = ACCT3
Firm = InternalCode( Enriched )
B acc2 = ACCT2
This kind of approach is used in high performance pricing engines (and even resulted in patent litigations that concluded that it was a well known approach: disclaimer: I'm not lawyer, and that's my personal understanding and not legal advice).
This approach can be used either in a record by record way (going through each set of mapping for each record). But it can also be used in a more efficient way if you've uploaded your CSV in a database, using some successive update statements that don't update account values already filled by previous steps.
Another approach could be to use some more sophisticated rule engine, and translate all your if-then-else into business rules. The advantage is that you don't have to determine the mapping tables as you have done. You don't have to think about mapping dependencies (e.g. if on ogf the mapping field is in fact determiend by a previous mapping). It's also easy to add new rules.
The inconvenience is that the rule engine is invoked for each CSV record. So it might be more heavy than the table based approach (see solution 2). Also, it's difficult for the rule writer to understand the interaction between different kind of rules.
If you don't want to use an existing rule based engine and develop your own, you could be interested in this SE question.