Hi and thank you for your reply.

>> 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.

Indeed and that is why we followed the suggestion!

>> 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.

I understand.

>> 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).

Well, thank you for the suggestion but this is an enormous amount of work (more than 5000 transactions).

I am very familiar with ISAM databases and the Advantage database engine (of which I assume you are using the local server). I beleive that the data is indeed in the original data set (the one looked at by the open payables report) but that some flushing of an index key somehow caused all the date fields to be pushed to an emptry state. The repair process would probably involve setting a relation into the other table where the original payment date information could be found and updating the value.

Can you refer me?

Thanks for all your help and,

Cheers, JK