Can we assume you understand how the CRC works?

crc16:
    mov si, data
    mov cx, data_length
    mov bx, 0
  .l1:
    lodsw
    xor bx, ax
    mov dx, 16
  .l2:
    shr bx, 1
    jnc short .l3
    xor bx, 0xa001
  .l3:
    dec dx
    jnz short .l2
    dec cx
    jnz short .l1
    

Post-invert
The same sort of error can occur at the end of a message. Appending 0 bits to a message is equivalent to multiplying its polynomial by x, and if it was previously a multiple of the CRC polynomial, the result of that multiplication will be, as well. This is equivalent to the fact that, since 726 is a multiple of 11, so is 7260.
A similar solution can be applied at the end of the message, inverting the CRC register before it is appended to the message. Again, any non-zero change will do; inverting all the bits is simply the most common.
This has an effect on one-pass CRC checking; instead of producing a result of zero when the message is correct, it produces a fixed non-zero result. (To be precise, the result is the non-inverted CRC of the inversion pattern.) This is still straightforward to verify.
(from Wiki)