Can I avoid using too many "if - else if" in the sample below?

Reducing complex nested ifs and elses is not a trivial task. This is a typical refactoring task which first of all calls for a good unit test coverage.

Now, how to tackle the problem in a systematic manner?

1. No restructuring but combine common terms into functions

I suggest to first not change the structure but simplify by combining common elaborate conditions into predicate functions. In your case (assuming names starting on capital letters are members of the class), convert

if (length >= 24 && Acct == strAcct && ...
...
else if (length >= 24 && Acct == strAcct && ...

into

bool IsAcct(int length, string strAcct)
{
    return length >= 24 && Acct == strAcct;
}
...
if (IsAcct(length, strAcct) && ...
...
else if (IsAcct(length, strAcct) && ...

Likewise convert

if (Effect != strReceive && strVal == "A") ...

into

bool IsDesiredEffect(string strReceive, string strVal)
{
    return Effect != strReceive && strVal == "A";
}
...
if (IsDesiredEffect(strReceive, strVal)) ...

2. List all conditions for each code branch

This is best done by first give each simple condition a code, e.g.

// A: IsAcct(length, strAct)
// C: code == strCode1
// D: Box.HasValues
// E: alk.Count > 1
// F: IsDesiredEffect(strRecieve, strVal)
// G: code == strCode2

The decorated code looks like this

if (IsAcct(length, strAcct) && code == strCode1)         // A && C
{
    if (Box.HasValues)                                   // A && C && D
    {
        if (alk.Count > 1)                               // A && C && D && E
        {
            if (IsDesiredEffect(strReceive, strVal))     // A && C && D && E && F
            {
                Method1();
            }
            else                                         // A && C && D && E && !F
            {
                Method2();
            }
        }
        else                                             // A && C && D && !E
        {
            Method2();
        }
    }
}
else if (IsAcct(length, strAcct) && code == strCode2)    // A && !C && G
{
    if (Box.HasValues)                                   // A && !C && G && D
    {
        Method3();
    }
}

This results in the following conditions for the methods

Method1() //  A && C && D && E && F
Method2() //  A && C && D && E && !F  || A && C && D && !E
Method3() //  A && !C && G && D

3. Re-arrange and simplify expressions

Here you need to know basics of Boolean logic transformations.

Method1() //    A && D && C && E && F
Method2() //    A && D && C && E && !F || A && D && C && !E
          // => A && D && C && (E && !F || !E)
          // => A && D && C && (!E || !F)
          // => A && D && C && !(E && F)
Method3() //    A && D && !C && G

Uncluttered:

Method1() //    A && D &&  C &&   E && F
Method2() //    A && D &&  C && !(E && F)
Method3() //    A && D && !C &&  G

4. Combining common expressions again

E.g.

Method1() //    AD &&  C &&  EF
Method2() //    AD &&  C && !EF
Method3() //    AD && !C &&  G

While extending the predicates accordingly:

// AD: IsAcct(length, strAct)
// C: code == strCode1
// EF: IsDesiredEffect(alk, strRecieve, strVal)
// G: code == strCode2
...
bool IsAcct(int length, string strAcct)
{
    return length >= 24 && Acct == strAcct && Box.HasValue;
}
bool IsDesiredEffect(ICollection alk, string strReceive, string strVal)
{
    return alk.Count > 1 && Effect != strReceive && strVal == "A";
}

5. Finally composing the reduced version

if (IsAcct(length, strAct))
{
    if (code == strCode1)
    {
        if (IsDesiredEffect(alk, strReceive, strVal))
        {
            Method1();
        }
        else
        {
            Method2();
        }
    }
    else if (code == strCode2)
    {
        Method3();
    }
}

Summary

This approach might look a bit overwhelming, I agree. But it provides you with a systematic approach for such complex transformation. The approach with the codes for the expressions (A, C, D, etc.) allows for easier dealing with the Boolean expression transformations. It also helps in a peer review/pair programming to have the condensed logic to discuss rather than having the logic cluttered with code details.

Don't forget to start with a good set of unit tests before refactoring decision trees!

Have fun!
Cheers
Andi

To illustrate another approach to re-factoring:

a. analyze the cases where analysis can be skipped:

if (length < 24) return;
if (Acct != strAcct) return;
if (! Box.HasValues) return;

b. Combine them into a "short-circuiting" OR:

if(length < 24 || (Acct != strAcct) || (! Box.HasValues)
{
     // throw an error ?
     // log a call that wasn't evaluated ?

     // do nothing ? 
     return;
}

Which of these (none, many, or, all of them) that you implement can be guided by your heuristic knowledge of what the most common parameter-values are in the most frequent calls to the method.

if (code == strCode2)
{
    Method3();
}
else if (alk.Count > 1)
{
    if (Effect != strReceive && strVal == "A")
    {
        Method1();
    }
    else
    {
        Method2();
    }
}
else if // alk.Count <= 1
{
     // throw an error ?
     // log a call that wasn't evaluated ?
     // do nothing ?
}

Note: I like the approach of "teasing out" the "no go" factors before more complex evaluation, because, imho, it makes it easy to insert logging, or error handling (or, unit tests?), without touching the rest of the code.

imho, re-factoring is both a skill, craft, science, and art, when it takes into account your prior experience and wisdom, and the unique application context in which code is executed.

In the "real-world," however, where you work, and who you work with, may constrain how, and when, you re-factor. I have seen a scenario where a new programmer on the team of a very complex application got carried away with re-factoring in part due to being in fear of the very hard work required to learn the structure and dynamics of the application. Unfortunately, the re-factoring they did introduced some bugs, as well as requiring an expensive test cycle, and their code had to be discarded. Yes, there was a failure of management there in letting the newcomer kind of "go off on their own."

When you see code like this:

if (A)
{
    if (B)
    {
        work();
    }
}

It is equivalent to this:

if (A && B)
{
    work();
}

With that in mind ...

if (length >= 24 && Acct == strAcct && Box.HasValues)
{
    if (code == strCode1)
    {
        if (alk.Count > 1 && Effect != strReceive && strVal == "A")
        {
            Method1();
        }
        else
        {
            Method2();
        }
    }
    else if (code == strCode2)
    {
        Method3();
    }
}