Reconciling credit card statements

[Jason Chu]

Every time I import transactions from my credit card the balance lines never match up.  I understand this is because transactions can be inserted inserted in history.  How do other people reconcile their credit card statements to make sure they have the correct balance for a given set of transactions?  I'm afraid if I don't do this I will end up missing or double counting a transaction somewhere and not accurately representing my debt.

Gnucash had a mechanism for reconciling a set of transactions with a statement, where it would change the state of the transaction to reconciled (y vs n or c) and would verify that all reconciled transactions at that point in time matched the statement balance.

[yegle]

If you have one balance assertion for each statement, you'll be able to reconcile each billing cycle separately.

On Sun, May 8, 2016 at 2:01 PM, Jason Chu <xen...@gmail.com> wrote:

Every time I import transactions from my credit card the balance lines never match up.  I understand this is because transactions can be inserted inserted in history.  How do other people reconcile their credit card statements to make sure they have the correct balance for a given set of transactions?  I'm afraid if I don't do this I will end up missing or double counting a transaction somewhere and not accurately representing my debt.

Gnucash had a mechanism for reconciling a set of transactions with a statement, where it would change the state of the transaction to reconciled (y vs n or c) and would verify that all reconciled transactions at that point in time matched the statement balance.

--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To post to this group, send email to bean...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/2a5a65cb-ba31-4a9c-b5c8-fcbaf6fb78e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Yuchen Ying
http://about.me/yegle

[Jason Chu]

The problem is that postings are inserted before the statement end in the next billing cycle (because of random delays in the charge processing systems) so the balance assertion can't be against any given date.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFL5w3X9m987Dk4NO8xaxczGjJDsjt2DGOoNoBwgVGqaPJOTuA%40mail.gmail.com.

[Martin Blais]

I see what you mean now. Just to be clear, let me paraphrase:

- You download a CSV or OFX file at date C

- The transactions in it span dates A -> B

- At the time of download, the transactions from dates B -> C haven't been included yet, but they exist (they are said to be "pending") and will later appear

- Your importer inserts the balance up to B at date C.

Later on, you import transactions from B -> C and the balance assertion fails.

The solution is simple: Have your importer insert the balance assertion at date B + one day.

If what I describe above is not the situation you're facing, it's possible you just need to go back in time at the first failing assertion and manually inspect the list of transactions to find missing ones that you may not have recorded in your input file. As a guideline, for credit cards, I tend to use a balance assertion for every download (every week or two) and it works fine.

(You can also insert balance assertions manually by logging into your online account and looking at the current balance and date.)

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFFHUgsLVOweX-YW2A4mNTYqDipSF3zR3VKPRJd4C%2Bn9TdE27w%40mail.gmail.com.

[yegle]

On Sun, May 8, 2016 at 9:00 PM, Jason Chu <xen...@gmail.com> wrote:

The problem is that postings are inserted before the statement end in the next billing cycle (because of random delays in the charge processing systems) so the balance assertion can't be against any given date.

There's an effective date plugin (don't remember the git repo though), which can help organize the transactions that happen on day X and settled on day Y.

For me I just move the transaction to the billing cycle that matches the statement, and add the real transaction date in the narration field.

[Zhuoyun Wei]

2016-05-09 04:00:52 Jason Chu <xen...@gmail.com>:

> The problem is that postings are inserted before the statement end in the next billing cycle (because of random delays
> in the charge processing systems) so the balance assertion can't be against any given date.

Why does the balance assertion not match any given date? I make a
balance assertion every month on the statement day. One needs to be
cautious that the balance assertion occurs at the beginning of the day,
prior to any real transactions: If you your statement day is 03, you
should use "XXXX-XX-04 balance Liabilities:XX" to assert your credit
card balance.

Martin is also working on a new directive "balance_end", enabling user
to insert balance assertions at the end of day:
https://bitbucket.org/blais/beancount/issues/118/create-a-balance_end-directive

> CAFFHUgsLVOweX-YW2A4mNTYqDipSF3zR3VKPRJd4C%2Bn9TdE27w%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--

Zhuoyun Wei

[Zhuoyun Wei]

2016-05-08 21:10:14 yegle <cny...@gmail.com>:

Ditto here. For credit card transactions, I use the settled date as
directive date in the Beancount file, and keep sale date in metadata.

> --
> Yuchen Ying
> http://about.me/yegle
>

> --
> You received this message because you are subscribed to the Google Groups "Beancount" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> beancount+...@googlegroups.com.
> To post to this group, send email to bean...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/

> CAFL5w3VEbJJAFTm3-kLea6xFWAwwVvcoZ77amufDka0MoDspiQ%40mail.gmail.com.

> For more options, visit https://groups.google.com/d/optout.

--

Zhuoyun Wei

[Jason Chu]

It's not even the importing, the statements have this artifact also.

Statement 1 covers 2016-01-02 to 2016-02-01.  It contains transactions between those dates.

Statement 2 covers 2016-02-02 to 2016-03-01.  It includes a transaction from 2016-02-01 (or even 2016-01-31!).  I assumed this was because the date of the transaction was the date it was charged, not the date it was debited (or whatever the term is) from the account.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/20160509041529.GB17975%40eden.wzyboy.org.

[Martin Blais]

Let's clarify this:

Credit card transactions and brokerage trades have two dates: AFAICT so far:

1. For CC, the "posted date" or "transaction date", for brokerages the "trade date"; this is the date at which you make the purchase or traded the stock (when it filled, not when you placed an order, e.g. a limit order could have been placed days before).

2. The "settlement date", which is the date at which the transaction is applied against your account.

The period between posted and settlement dates is a sort of limbo ("settlement period"? there may be a better name for this).

What may be happening is that you're looking at transaction dates but the report is generated for settlement dates. That would explain you seeing some dates prior to the download.

If you'd like to keep things simple, import everything at settlement dates. That's what I do myself, and for the most part my balance assertions don't have to be moved manually too often.

One day the whole issue of posting precise dates for each side of a transaction will be handled elegantly. I haven't cared too much myself yet, but I see so much interest for it from many people.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAFFHUgsxUWq7YbPrvoReBYoB9adiVHppgj_Bdhn7SqG-nnJzUw%40mail.gmail.com.

[Jason Chu]

Yes, I realize there are two dates.  Unfortunately the ofx files that I download don't contain both dates, only the posted date.

I think I will end up going back through my statements and fudging some of the dates so that I can make meaningful balance assertions matching up with the statement dates... blegh.

To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhOHTy7Jshg07CPjsJcCO1UhCauNHSHPZ-NjKJ%3DaqJSkhw%40mail.gmail.com.

[Simon Michael]

On 5/8/16 9:42 PM, Martin Blais wrote:
> One day the whole issue of posting precise dates for each side of a
> transaction will be handled elegantly. I haven't cared too much myself yet,
> but I see so much interest for it from many people.

Yes, every newcomer runs into this at some point. The elegant solution
is allowing postings to have their own dates, right ? Ledger and hledger
also have the the "auxiliary dates" feature, but I think that one is the
wrong solution.

http://hledger.org/journal.html#posting-dates

[Martin Blais]

Yes. But that shouldn't come at the expense of balancing transactions. What I want to do is support dates on postings but replace the postings by ones to limbo accounts so that clearing over a split posting still balances to zero.

[Red S]

On Sunday, May 8, 2016 at 9:01:03 PM UTC-7 xen…@gmail.com wrote:

The problem is that postings are inserted before the statement end in the next billing cycle (because of random delays in the charge processing systems) so the balance assertion can't be against any given date.

Necroing this thread: I fixed this annoyance in beancount_reds_importers (see README.md). Also see this article. Extract: 

The Balance Assertion Date

The date of the balance assertion matters. Consider this example of an OFX file for a credit card:

• posting date of first/last transactions: Jan 1 — Jan 31
• statement download date: Feb 8

Is Feb 8 a good choice to to assert balance? Typically not. subsequent OFX download might include currently uncleared transactions for Feb 6, which would invalidate and trip up the Feb 8 assertion, requiring manual intervention.

smart dates: To attempt to avoid this, a good idea is to set the balance assertion date to either two days (fudge factor to account for pending transactions) before the statement’s end date or the last transaction’s date, whichever is later.

beancount_reds_importers offers several choices for balance assertions, as a part of the importer configuration:

• smart: smart date (default; see below). To choose a different fudge factor for smart dates, simply set balance_assertion_date_fudge in your config.
• ofx_date: date specified in ofx file
• last_transaction: max transaction date
• today: today’s date

If you want something else, simply override this method in individual importer. I use the smart option, and it has been consistent and dependable for me.

​