That's part of the problem with corrupted data (in this case, missing Transaction Matching records) and why we suggested doing this on a copy of the data.

The rebuild process will not re-match existing payments to invoices and create records - that could potentially mess things up really bad. Instead it found that an invoice did not have a matching payment and set the current amount back to the original amount.

My guess is that if you were to do a new manual check batch and entry for the vendor BRA01 mentioned in an earlier posting, you will see the invoice but not the PA payment. If you do see the payment in the grid then this is great! Apply to both the payment and invoice (net to zero) and post - this will set the current amount of both to zero - and will allow purging to history later on. If you don't see the previous payment then this indicates that you have records that cannot be purged (and the data is still corrupted).

So in seeing this, you might decide that the Rebuild will not put the data in a place where you can move forward from here.

From the copy of the data you have (prior to running the Data Integrity Check and Rebuilding), are the Current Amounts for both the Invoice and Payment equal zero? If so, you may be able to run Period End in order to clear these out of current transactions. If you try Period End on the data copy and this works, then great! If they are not purged, then your data is corrupted too badly for an automatic process like Rebuild to fix it, and it will need the attention of a Database Repair expert.