The signature over PKCS#10 is defined in RFC 2986, specifically section 4.2 (on page 7).
The signature process consists of two steps:
The value of the
certificationRequestInfo component is DER
encoded, yielding an octet string.
The result of step 1 is signed with the certification request
subject's private key under the specified signature
algorithm, yielding a bit string, the signature.
The signature is over all the significant information in the request and includes all the DER-encoded attributes in the PKCS#10 signing request.
If there are any missing or additional attributes in the PKCS#10 certificate request, or if any of the attributes differ by even one single bit, then the signature will be completely different. This could include using a different string encoding (printable ASCII string vs UTF-8), but also different dates etc.
If you want to find the difference, you can decode your certificate request here. You might have to strip your request in PEM format or convert your request in DER format to base 64 before using this tool. You could also use
openssl asn1parse functionality for this.
Finally, it could also be that a different signing algorithm is used, e.g. PKCS#1 v1.5 padding vs PSS padding. They would both generate the same amount of bytes. PSS is non-deterministic (uses a random bytes) by the way; if it is used the signature would be different each time regardless of the input. Normally PKCS#1 v1.5 padding is still used though.
As Dave mentions, the best way to validate the correctness of a signature is not to compare it but by verifying the signature and validating the attributes, possibly by using other software. That way non-significant changes won't play a role within the validation.