Most systems report a successful send without ever reading the value back to see whether the other end actually stored it. That gap is where a week of wrong pricing hides.
When a channel manager shows a green tick next to an update, it usually means one thing only: the other end returned an acknowledgement. That is a claim about the request, not about the stored value — and the two come apart more often than the interface admits.
Most systems stop at the first. Some reach the second. The third is what actually tells you the guest will see the right number.
An outright failure is easy: it shows red and you fix it. The expensive case is the update that returns success while quietly discarding part of its payload — a rate that applied but a minimum stay that did not, or one room type in a batch of eight that was rejected for a reason buried in a warnings array.
From the dashboard, nothing looks wrong. The listing sells all week at a price you stopped using in March.
After an update is sent, the system waits for the channel to finish processing, fetches the current stored values for exactly the dates and fields it just wrote, and compares them one by one. If any value does not match, the update is marked failed and the status names the channel and the field.
None of this is exotic engineering. It is simply the difference between a system designed to look reliable and one designed to be checkable.