Guides

Working with credit cards

Paying for things on a credit card and settling the balance later is one of the most common ways people spend, so Duration supports it directly. It also treats a card a little differently from how you might expect, and that difference is worth ten minutes up front — it makes everything else about cards fall into place.

The one idea to hold on to: Duration keeps your card legible; it does not pay the card. It records what you spent, shows whether your money covers what you owe, and flags when a purchase needs you to move money — but the payment itself happens through your own bank arrangement, not through Duration. Everything below follows from that.

A card is an account you owe on

In Duration every account has a role. A checking account is a debit account — money you have. A credit card is a liability account — money you owe. When you add a card, choose the liability role, and Duration maps it to the out-of-pocket horizon: the near-term, “this is day-to-day spending money” tier.

Because it’s a liability, the card’s balance is negative from Duration’s point of view — it pulls the out-of-pocket horizon’s funded figure down by exactly what you currently owe on the card. That is the whole trick, and it’s what makes the rest work without any special “credit card mode.”

Adding one

Go to Accounts and add an account.
Give it a label (“Visa”, “Amex”, whatever you’ll recognise on a statement).
Set the role to liability.
Map it to your out-of-pocket horizon.

That’s it. There’s nothing else to configure — no billing dates, no statement settings. (Earlier versions of Duration asked for a statement day and a due day; they’ve been removed, for reasons we explain at the end.)

Spending on the card

When you categorise a card purchase to a bucket, two things happen at once:

the bucket you chose goes down — the spending has happened, and that envelope now holds less; and
the card’s balance goes up — you owe the issuer more.

Those two moves are equal and opposite within the out-of-pocket horizon, so an ordinary card spend leaves your drift untouched. Nothing looks off, nothing needs fixing — you spent budgeted money, and the books simply record that you happen to owe it to the card for now instead of having paid cash on the spot.

This is the same experience whether you use a card for everything or never touch one. If you pay straight from a debit account, the card branch just stays dormant.

Importing card transactions

Your card is its own account, so it gets its own import. Export the card’s transactions from your bank or card issuer and import them the same way you import any account — Duration reads each row, proposes matches against anything you’ve already entered, and lets you confirm the batch. See Import and reconcile for the full flow.

A couple of things worth knowing, because cards are where they show up most:

Pending vs settled. Many cards show a purchase almost immediately, sometimes as a reserved or “pending” amount, then adjust it slightly when it settles a few days later. Import when the rows have settled if you can; if a pending amount shifts between exports, the staged review and the balance check are there to help you merge the corrected row rather than double-count it.
Reconcile to the card’s balance. After an import, the card account should reconcile to the balance your statement or app reports — the amount you owe. If it doesn’t, a row is missing or duplicated, and the reconciliation check will say so.

Allocating, and paying the bill

You budget for card spending exactly as you budget for anything else: money lands in ready-to-allocate, and you allocate it out to your buckets. Nothing about a card changes that.

The one thing to keep straight is paying the card. When you pay your card from your debit account, that is a transfer, not a spend — money moves from “cash you have” to “knocking down what you owe”, and no bucket is touched. The spending was already recorded, purchase by purchase, when it hit your buckets. If a card payment also debited an envelope, you’d be counting the same expense twice. So: spend when you buy, transfer when you pay. Duration is built around that distinction, and it’s why you never need to “budget for the credit card bill” as a line of its own — you already budgeted for the things on it.

When a purchase crosses horizons

Here’s the one case where a card actively asks something of you. Suppose you put a large purchase on the card, but the money for it lives in a longer-term horizon — say you bought something out of money you’d been keeping invested. Now the two halves of the spend land in different horizons:

out-of-pocket is short (you owe the card, but the budgeted money isn’t sitting in cash), and
the longer horizon is over (its money hasn’t been spent from where it physically sits yet).

Duration reads this as a timing drift and, on the next sweep, suggests a harvest: sell or move from the longer horizon up to your debit hub, so cash is in place to cover the card. It’s the ordinary sweep machinery — see Sweep to close drift — pointed at a card. You decide whether and when to act on it; Duration proposes, you dispose.

Coverage: does your cash cover the card?

On the sweep view, Duration shows an out-of-pocket coverage summary — the single, honest liquidity question: does your debit account cover what you owe on your cards? It breaks down as:

Card liability — the total you currently owe across your cards.
Expected repayments — if someone owes you a share of a card spend (a receivable, e.g. a split with a partner), the amount you expect back.
Net shortfall — what you’d still need, assuming those repayments arrive before the bill is drawn.
Gross shortfall — what you’d need if no repayment arrives and you cover the whole thing yourself.

Net versus gross is presented as a choice, never applied for you. It’s a read on your position, not an instruction.

What Duration deliberately does not do

Duration does not track your card’s due date, does not count down to it, and does not remind you to pay. That’s a deliberate choice, not a missing feature. Three reasons:

Duration doesn’t pay the card. The payment happens through your own bank — most often an automatic direct debit that draws the bill from the account your salary lands in. Duration never moves that money, so counting down to it would be theatre.
A reliable “by when” isn’t knowable from your data. A transaction export lists what you spent, not which statement each purchase falls on. Guessing a deadline from that tends to raise false alarms — flagging a recent purchase as urgent when it’s really on next month’s bill — and a budgeting tool built to keep you calm and in control shouldn’t manufacture urgency.
The number that matters is exact anyway. What you need to cover a card is your out-of-pocket position, which Duration knows precisely, and your total card liability is always a safe upper bound. None of that depends on a date.

So the honest signal Duration gives you is a standing one: here’s what you owe, here’s whether your cash covers it, and here’s the one purchase (if any) that needs a move. When and how the bill is actually paid stays where it belongs — in how you’ve set up your finances outside Duration.

Your setup will differ — and that’s fine

How credit cards work varies a lot from person to person and country to country, and Duration is deliberately agnostic about it:

Who issues the card. A card from your everyday bank often settles by automatic direct debit from that same bank’s account; a card from a separate issuer might be paid manually, or drawn from a different account. Both are just “a liability account you pay by transfer” to Duration.
How it’s paid. Automatic (you never look at the invoice), manual (you pay the statement each month), or in full versus over time — Duration doesn’t need to know. It records the payment as a transfer whenever it lands in your import.
When it’s billed. Statement cycles, grace periods, and due dates differ by issuer and country, and some places lean heavily on the “statement balance vs. current balance” distinction while others don’t. Duration doesn’t model any of it, so none of it can be set up wrong.

The point of leaving all of that out is that the model underneath is the same for everyone: a card is money you owe, spending is recorded to buckets, paying is a transfer, and the sweep steps in only when a purchase crosses horizons. Whatever your card and country do, that stays true.

Last reviewed: July 2026.