Will the Wiegand reader be able to read the same serial number as the phone?
Wiegand readers for 13.56 MHz (more specifically ISO/IEC 14443 Type A) typically read the anti-collision identifier of cards/tags. The phone also seems to display the anti-collision identifier (UID) to you. So, yes, both devices read the same data element.
However, as you correctly found out, the reader only transmits a 26 bit value over the Wiegand interface (actually only 24 bits, since two of them are parity bits). As the UID has either 4 bytes, 7 bytes or 10 bytes, it needs to truncate the UID into a 3 byte value to transmit it over the Wiegand interface.
What data can I expect from a Wiegand reader?
Frames on the Wiegand interface look like this:
b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 b10 b11 b12 b13 b14 b15 b16 b17 b18 b19 b20 b21 b22 b23 b24 b25
PE D23 D22 D21 D20 D19 D18 D17 D16 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 PO
The first line being the bits numbered as they arrive over the Wiegand wires. The second line being the same bits as they are interpreted by the receiver, where PE (b0) is an even parity bit over D23..D12 (b1..b12), PO (b25) is an odd parity bit over D11..D0 (b13..b24), and D23..D0 are the data bits representing an unsigned integer number (actually two, since the upper 8 bits are the site code and the lower 16 bits the tag ID).
Even though there is a logical split into site code and tag ID, these readers typically just use a truncated form of the tag ID as the 24 bit value.
How this value would map to the hexadecimal value you received on the phone strongly depends on how that hexadecimal representation was created (specifically its byte order). It might be as easy as just taking the last 3 bytes (F52327), but it could just as well be that it's 1BF523 (or any byte-reversed (or even bit-reversed) variation of that).
UPDATE: Regarding the values that you get for your readers...
First of all, you seem to have dropped leading zeros from the values. For instance, 1BF52327 is a 4-byte value and, consequently, has 32 bits:
1 B F 5 2 3 2 7
0001 1011 1111 0101 0010 0011 0010 0111
The same seems to be the case for the values received from the readers (either that or the library automatically dropped the leading parity bit or dropped both parity bits and added an arbitrary number(?) of zeros at the end of the values).
So your values are:
1101 1000 1101 1100 0000 1010 1110 0100 0000 0000
1101 1100 0000 1010 1110 0100 0
As you found out yourself, these clearly correlate in that one byte is missing at the beginning and that the value from the HID reader is filled with more zeros in the end.
Looking more closely, these values also correlate with the first binary value. The trick is to invert the values first. Thus, the values
1101 1000 1101 1100 0000 1010 1110 0100 0000 0000
1101 1100 0000 1010 1110 0100 0
become
0010 0111 0010 0011 1111 0101 0001 1011 1111 1111
0010 0011 1111 0101 0001 1011 1
For the value from the Wiegand reader, this would also fix the trailing odd parity bit (PO) since there are 7 '1' bits (incl PO) now (though this could just be coincidence).
You can now see that these values represent exactly the first value in reversed byte-order. If you reverse the byte-order of
1 B F 5 2 3 2 7
0001 1011 1111 0101 0010 0011 0010 0111
you get
2 7 2 3 F 5 1 B
0010 0111 0010 0011 1111 0101 0001 1011
Comparing that to the other two values, you see that they match:
0010 0111 0010 0011 1111 0101 0001 1011
0010 0111 0010 0011 1111 0101 0001 1011 1111 1111
0010 0011 1111 0101 0001 1011 1
Consequently, the value that you receive from the HID reader represents 2723F51B and the value that you receive from the Wiegand reader represents 23F51B. Hence, the byte 27 is truncated.
