> In general, I think that we must assume no correlation between importing data
> and reconciliation. All that we know is that each entry imported from the
> bank must appear in the ledger and that it has cleared the bank.
> A JE must progress through the following "reconciliation states"
> 1) Entered
> 2) Cleared
> 3) Candidate
> 4) Reconciled
That's right. Only I like to add a note to each candidate and reconciled
transaction to pair it off with a specific line on the bank statement.
My credit card statements contain line numbers, and i use them
in the ledger to establish a one-to-one correspondence.
>
> The act of reconciliation is that of selecting candidates so that they match
> the statement to which they are being reconciled. When it is complete, the
> "commit" operation moves all the candidates to the reconciled state.
> >From a user's POV, it is convenient to be able to invoke a function which
> moves all "Cleared" entries to the "Candidate" state if they are on or before
> the closing date of the statement. The user can then manually select
> exceptions.
Except that when I reconcile, I match up the transactiuons with the statement
one at a time and check them off on the paper statement. If I Converted
I would lose track of which lines on the paper statement had been matched.
> I don't think that it is necessary to attempt to remember the complete text.
> Transaction(cheque) identifier(number) and amount should be adequate to
> identify most transactions once they have been matched the first time.
Except a lot of the transactions I get don't have meaningful numbers on
the bank statement -- whether .qif or paper.
-- hendrik.
