Crossposted on Stackoverflow. It's polite to mention other places on the web where you asked the same question so that work doesn't get doubled.

Some notes on your post:

    $x=grep /$xrefvalue/, @xreflines;
[download]

Instead of searching through the @xreflines like that, use instead a hash as the datastructure:

my %xreflines = map { $_ => 1 } grep /\S/, <XREF>;

...

    $x = $xreflines{ $xrefvalue };
[download]

This removes the loop and changes it into a direct lookup whether the xref exists.

Also, for reading a (comma, or semicolon-)delimited file, consider using Text::CSV_XS instead of splitting the data yourself.

@xreflines=<XREF>;
#remove the blank lines from the araary
@xreflines = grep /\S/, @xreflines;
[download]

You didn't chomp to remove newlines.

    $x=grep /$xrefvalue/, @xreflines;
[download]

if @xreflines contains the values 30368021983, 30368021984 and 30368021985 and $xrefvalue contains the value 3036802198 then it will match all three, incorrectly.

As Corion points out, it is better to use a hash:

my %xreflines = map { /(\d+)/, 1 } <XREF>;


    unless ( exists $xreflines{ "$DISTID1$CUST1" } ) {
        print LOG "\$x value is $x \n";
        print LOG "\$line is $line \n";
        print XFILE "$line \n";
    }
[download]

A few other changes might improve your code. Insert these pragmas:

use strict;
use warnings;
[download]

You don't need to store your customer file into an array (@lines) and then read the array, this leads you to process twice the same data, which is a waste of time. Do your checks when reading your customer file line by line;

Use the three-argument syntax of open and use lexical file handles (see examples below).

This could lead to something like this (untested):

use strict;
use warnings;
# Read the values from XREF into a hash
my $xref = "input_file.txt";  # put here real filename
open my $XREF, "<", $xref or warn "Could not open $xref $!";  # A more
+ detailed message can sometimes be useful
my %xreflines =  map { chomp; $_ => 1 } grep /\S/, <$XREF>;     # popu
+lating the hash with the content of the xref file
close $XREF;

my $goodfile = ...;                                 # insert the name 
+of the output file here
open my $XFILE, ">>", $goodfile or warn "Could not open $goodfile $!";

my $outfile = ...;                                  # insert the name 
+of the customer file here
open my $CUSTOMERFILE, "<", $outfile or warn "Could not open $outfile 
+$!";
while (my $line = <$CUSTOMERFILE>) {
    my ($dist, $cust) = (split /;/, $line)[0,1];    # no need to chomp
+ the fields, there are other fields afterwards in the line
    my $key = "$dist$cust";                         # Building the loo
+kup key
    unless (exists $xreflines{$key}) {              # hash lookup
        print $XFILE "$line";                       # printing the lin
+es whose ID is not found in the cross ref file
    }
}
close $XFILE;
close $CUSTOMERFILE;
[download]

print LOG "\$xrefvalue is $xrefvalue \n";
$x=grep /$xrefvalue/, @xreflines;

I don't see where  $xrefvalue is being declared and initialized. I assume it's being built from  $DISTID1 and  $CUST1 in something like the way that Laurent_R shows here:
    my $xrefvalue = "$DISTID1$CUST1";
If so, there's a potential problem because two records like
    3696693;5308;;BJS BREWHOUSE;2631 EDMONDSON RD;...
    369669;35308;;HORSESHOE ROAD INN;12 3RD ST;...
will have the same  $xrefvalue value, "36966935308", unless there is some unstated rule that tells you this can never happen.

Better, IMHO, to use a non-numeric separator to guarantee unambiguous cross-ref values:
    my $separator = ';';
    ...
    my $xrefvalue = "$DISTID1$separator$CUST1";
A semicolon seems nice because the CSV field separator is already a semicolon.

The advice to build a cross-ref lookup hash seems very, very good. I imagine the rest of the code might look a lot like the code in Laurent_R's post except the split statement could be
    my ($dist, $cust) = (split $separator, $line)[0,1];
or
    my ($dist, $cust) = split $separator, $line, 3;
You don't say how big your database is, but a hash could accommodate tens of millions of cross references in system memory for very fast lookup; much more than that and you're looking at a database. (Other approaches, like using Text::CSV_XS or a regex field extractor, or perhaps emulated multidimensional hash keys might be better (or sexier), but let's just take one step at a time!)