Kachink

Kachink

Kachink is a personal finance ledger the agent reads and writes during conversation. Entries persist, so the user can ask about any past month without re-supplying the data. Every amount is stored in the currency it was spent in, alongside a converted value in the user's base currency.

Recommended read order

1. Check the user's plan and usage before a batch of writes, so limits are known before hitting one.
2. List the available categories before categorizing anything. The set is per-user and can be customized.
3. Read the month you intend to discuss. Summaries are month-scoped.

Data model

• Transactions are the base unit. Each is an expense or income with an amount, a currency, a free-text description, a category, and a date. Date defaults to today when the user does not say otherwise.
• Base currency is the single currency all reporting rolls up into. It is set automatically from the user's first logged transaction and can be changed later.
• Converted amounts are computed at write time using that day's rate, then frozen. Editing a transaction's amount or currency recomputes it. Historical entries keep the rate that applied on their own date, not today's.
• Categories are per-user. There is a built-in set, and the user can add, rename, or remove their own. Removing a category remaps its existing transactions rather than deleting them.
• Recurring rules generate a transaction automatically once a month. They are templates, not transactions: creating one does not by itself create history beyond the current month's charge.
• Plan determines limits. Free accounts are capped at 50 transactions per month and 3 active recurring rules. Paid accounts have neither cap.

Write workflows

• Log spending or income: amount, currency, and description are the meaningful inputs. Ask for the category only if it is ambiguous, and prefer an existing one.
• Correct an entry: edit in place rather than deleting and re-logging, which preserves the original date.
• Bulk recategorize: a batch edit exists for reclassifying many transactions at once. Prefer it over looping single edits.
• Automate a fixed monthly charge: create a recurring rule with the day of month it lands on.
• Show the picture: a visual monthly dashboard renders as an interactive panel beside the chat, with month-to-month navigation. Prefer it over reciting numbers when the user asks how a month went.
• Hand back the data: a full export is available on request.

Multi-currency

The user can log in any currency and switch mid-conversation without setup. Reporting always rolls up into their base currency.

Currencies outside the supported conversion set still log successfully, but with no converted value. Those entries appear in the ledger and are excluded from base-currency totals rather than being counted at a wrong rate. Say so plainly if the user asks why a total looks short.

Gotchas

• Never infer the day of a recurring charge. It must come from the user explicitly. Today's date is not a hint. Valid days are 1 to 28, so that every month behaves the same.
• Creating a recurring rule whose day has already passed this month backfills that month's charge immediately. Expect one transaction to appear right away.
• Recurring charges post on a daily schedule in UTC. A rule created late in the user's day may not appear until the following calendar day in their timezone.
• The base currency is set from the very first transaction. If the user logs a one-off foreign expense before anything else, they will be reporting in the wrong currency until it is changed.
• Amounts are stored as entered, so a total shown in the base currency will not equal the sum of the raw amounts when several currencies are involved.
• Hitting a free-plan cap fails the write and says so. It is not a silent partial success, so do not retry the same entry.