I agree with the above, you must check always for framing and other Rx errors.
I always first suspect the baud rate. Try setting BRG one step higher or lower, especially if you see framing errors. Try using a scope to measure the actual baud/bit rate coming out of each device and compare. You must be within 4% error (so each side no more than 2% error high/low from the desired rate). An error of just 5% doesn't sound like much, but consider there are ten bits in each frame (start, data*8, stop), so the tenth bit in each frame will be more 50% out of phase. Then one receiving side will likely see frequent errors. Often when the baud rate error is marginal, only one side sees framing errors.
Personal anecdote: I recently set up a terminal server (box with Ethernet and a bunch of network-accessible serial ports) and was getting strange errors talking to many devices. I scoped the signals to the baud rate and saw it was about 4 % low at any baud rate setting. The other device was maybe 1 % high. This caused errors. The fix was easy, just replace a 25 MHz oscillator with a (custom made) 26 MHz one, forcing the baud rate to be always 4% higher. It is now spot-on and can talk error free to everything I have plugged into it.
I just saw your post on Parity. Parity is most often not used. You can only use it if the other device does too, and it very very likely does not. There is an extra data bit sent as parity. For PICs, you need to calculate the bit based on your data, then set the (9th) bit in the appropriate register before writing to TXREG. On the receive side, you extract the parity (9th) bit before reading from RXREG, then calculate desired parity from the data bits and compare. Don't concern yourself with this as your device almost certainly does not use it.