This is just a crude outline, but given the large number of different record types (judging by the values in field 1) I would use a hash with keys consisting of the various types you are interested in and the values being a hashref that includes formatting strings for sprint. Something like this:

# This is NOT real code, but just a concept

my %record_types = (
    99HEADER => {
        format => "%s %s",
        code => undef,
    },
    99INSFAC => {
        format => "%s %s %s %04.2f",
        code = >\&process_99insfac,
    },
};

for my $line ( @input_lines ) {
    my ($rec_type,@rec_data) = split(/|/,$line);
    next unless exists $record_types{$rec_type);

    # Call a pre-processor if present, maybe skip empty records.
    # Note, the syntax for a proper dispatch table might be wrong here
+. You
    # will probably need to play with this a bit, but it is nifty when
+ it works.
    next if defined( $record_types{$rec_type}{code} )
        && !&{$record_types{$rec_type}{code}}( data => \@rec_data );

    say sprint($record_types{$rec_type}{format},@rec_data);
}

exit;

sub process_99insfac {
    my %args = @_;
    my @rec_data = @{$args{data}};

    return unless $rec_data[2]; # no date? nothing to do
    $rec_data[3] = some calculation; # do something nifty here

    return 1;
}
[download]

This is a very crude presentation, but I think you can get the idea and can see that you can take advantage of the type hash by adding more info such as code references to sub-routines to do any special processing if needed. You would need to track entering and leaving each new record structure, but I doubt you would have much trouble with that logic. This approach should give you a lot of flexibility for layout and dealing with the different sub-record types.

Update: added example for a preprocessor code ref.