Feature Request: Support Negative Transactions for Reimbursements / Split Expenses

[TzuH-Hsu]

Describe the feature

Allow expense transactions to have negative amounts, so reimbursements and split expenses can be recorded as offsets to the original expense, instead of being logged as income.

This would enable users to correctly net out reimbursed or split expenses within the same category, without inflating income or total spending.

Why is this feature important?

The current workflow for reimbursements typically requires:

1. Recording the full payment as an expense
2. Recording the repayment as an “income” (e.g. Other income / Reimbursement)

While the net balance may be correct, this approach causes several issues:

• Reimbursements are not real income, but are counted as such in reports
• Expense totals are temporarily inflated
• Users must rely on tags or category exclusions, which:
  • Also exclude the user’s own share of the expense
  • Make spending analytics less accurate and more complex

Supporting negative expense transactions solves this cleanly by allowing reimbursements to directly offset the original expense category, keeping reports accurate by default.

Example use case

Shared subscription (3 people):

• Total payment: $900
• User’s own share: $300
• Paid upfront by the user
• Amount to be reimbursed: $600

Current workaround

Users can already approximate this by splitting the transaction:

• Expense: $300
  Category: Subscription
  Note: Personal share

• Expense: $600
  Category: Reimbursement
  Tag: Split / Reimbursement
  Note: Paid on behalf of others

• Income: $600
  Category: Reimbursement

Then, the reimbursed portion must be excluded manually.

Limitations of this approach:

• Requires extra manual steps and mental bookkeeping
• Reports are only correct after applying exclusions, not by default

With negative transactions

At the time of payment

• Expense: $900
  Category: Subscription
  Note: Shared subscription (3 people)

When reimbursement is received

• Expense: - $600
  Category: Subscription
  Note: Split expense reimbursement

→ Subscription spending correctly shows $300
→ No artificial income is created
→ Clean monthly and yearly reports

Additional context

• Negative transactions would make the default state correct, instead of relying on post-hoc exclusions during analysis.
• This feature would significantly improve handling of:
  • Split bills (AA)
  • Shared subscriptions
  • Reimbursements
  • Business expenses paid personally
• Even a limited implementation (negative amounts allowed in expense categories) would already solve most of these issues.

[TzuH-Hsu]

After thinking more about this, and given that Sure is bank-sync driven, negative transactions would not come from the bank feed itself, but from a user-created offset layer on top of bank-synced data.

A common real-world scenario is when payment and reimbursement happen across different accounts.

Example:

• I pay $900 from Account A for a shared subscription (bank-synced expense)
• A friend later reimburses me $600 to Account B (bank-synced inflow)

Both transactions are valid and should remain unchanged in their respective accounts.
The missing piece here is not the bank data, but the semantic link between these two transactions:

• The $600 inflow in Account B is not income
• It is a reimbursement offset for the subscription expense paid from Account A

With support for negative expense (or offset) transactions, a user could:

• Keep the original $900 expense in Account A
• Keep the $600 inflow in Account B
• Create (or convert) a transaction representing −$600 against the Subscription category

Result:

• Net subscription spending is correctly reported as $300
• Account balances remain accurate
• No artificial income is introduced, even across multiple accounts

[jjmata]

My current way of handling this here and in Quicken for many years (to keep "the books" correct accounting-wise) is to use categories. So basically the offsetting happens because by both transactions belonging to the same category it nets out. Does it not work that way for you?

[TzuH-Hsu]

Thanks for the explanation — I tried this approach (assigning both transactions to the same category), and I think I understand the difference more clearly now.

In this example, just focused on Digital Contents / Services, which is configured as an expense category.

As shown in the chart:

• The inflow side includes the reimbursement $441
• The outflow side includes the full upfront payment, including the portion paid on behalf of others $8,176

From a cash-flow perspective, this representation is correct and truthful — it accurately reflects what happened at the bank level.

The issue appears when a user’s intent is to analyze and understand their own personal spending, which is one of the core purposes of a personal finance system.

In this context, the Digital Contents / Services category does not net out:

• The reimbursed amount remains visible as inflow
• The full payment remains visible as outflow

As a result, my spending in this category is overstated, even though the overall cash flow is balanced and accounting-wise correct.

So the problem is not incorrect data, but a mismatch between money movement and spending responsibility.
The category works well for tracking where money moved, but less well for answering the question: “How much did I actually spend on this?”

[jjmata]

You're absolutely right! My first observation/reaction before digging into other product areas is that the Sankey chart should "net amounts out" and not ever put expenses on the left-hand side. Also the outflows could be improved though @sokie intended them to be true outflows, maybe a setting (as much as I hate them!) is in order there.

Are there other places where "netting out" via categories doesn't work that we need to include in this work?

[TzuH-Hsu]

That makes sense to me, and I agree it’s hard to assume whether most users expect true outflows or netted spending. A setting that allows users to choose the interpretation seems reasonable, since intent can differ between cash-flow tracking and spending analysis.

Another place where category netting currently breaks down is Reports → Transactions Breakdown → Income / Expenses by Category.

Overall, the mismatch is most noticeable in three areas: Sankey charts, Outflows, and Category Breakdown reports.

[jjmata]

Let's dig a bit deeper, @sokie recently added both Outflows and Reports so he can share his thoughts on how much this would complicate those implementations.

[jjmata]

So I did a quick test, and it doesn't works in Outflows with accounts that are bank sync either:

And the transaction list adds up balance well:

It gets registered "weird" as income which means something completely different (it's an expense ... just a "refund" of an expense)

This is the first thing we need to fix and see what else breaks. :-)

[jjmata]

Not an easy one to tackle, if you believe Opus 4.5 🤖

[TzuH-Hsu]

Yeah, that breakdown makes sense — it touches core classification, aggregation, and presentation layers, so definitely not a small change.

[m42cel]

I'd like to chime in since I had the same issue with reimbursements. It would be really nice to be able to match two transactions and mark one as reimbursement of the other. Sometimes you also just return things and get the full price refunded to the same account. In this case there could even be an automatic matching, just like with transfers but now on the same account.

For reimbursed or partly reimbursed expenses it would be nice if the expense amount was reduced by the reimbursement.
There's one edge-case that would also have to be covered in some way: If the reimbursement is larger than the expense, for example if you advance something for a friend and he just rounds up when he repays the amount.

For now I just created an income category "Reimbursement" so I can see what part of the income is not really income.

Contrary to the suggestion of this discussion I'd probably not add negative expenses but let them be income, but link them just like with transfers.

[CylonN8]

For reimbursements, maybe have an option to select which transaction was reimbursed (partially or fully), so the reimbursement is integrated at the original transaction date in the budget and not treated as income in reports (Sankey chart, etc.)

[m42cel]

Yeah, thats exactly what I had in mind. It should just reduce the actual expense.

In the case where the reimbursement is larger than the expense it would count as some kind of income. I also noticed another case where that often happens, which is business trips. I first pay from my own account and then create travel expense report. Additionally to the actual travel cost I get a meal allowance. So the reimbursement of the travel expense report is larger than the costs alone. Also the reimbrusement usually happens before the credit card statement.

And it would be great if multiple transactions could reimburse a single expense. For example if you pay for a group and then the individuals send their shares as individual transactions.

[Zeor-Xain]

Hello everyone.

There is a possible accounting approach to meet the requirement without needing refactoring.

However, it is quite laborious for accounts that use Import/Sync.

Sure's (current) architecture offers Account Types which can be Assets or Debt/Liabilities. And also transaction types Expense, Income, and Transfer, which require a positive value.

This model is similar to standard accounting, with accounts of opposite natures (Asset/Debt) that receive transactions or transfers between them.

Scenarios:

I believe the scenarios detailed above can be summarized into the following variations:

Cash disbursement:

• value: 900

Reimbursement. Values may vary:

• Expected: 600
• Higher than expected: 601
• Lower than expected: 599

Reimbursement parameters:

• In 5 minutes or in 45 days. (same date / different date).
• In the same account or in different account(s). (including credit card accounts)
• Reimbursed in full or partial amount.

Accounting Consideration

In these scenarios, the reimbursement can be considered a "Cash Advance":

• I paid 900, where 600 is a friend's responsibility:

  • My expense is 300; I advanced 600 to the friend and will receive it later, or on the same day.
  • My expense is 300, I advanced 600, but received 599 = my extra expense of 1.
  • My expense is 300, I advanced 600, but received 601 = my extra income of 1.

• My purchase was 1000. I returned items totaling 50:

  • My expense is 950. I expect to receive the advanced 50 back, whether in 5 minutes or 45 days.

Sure

I would create an "Other Asset" account called "Cash Advance" for accounting purposes.

In this account, I don't need to reconcile balances with statements.
The "Other Asset" account is convenient for this because it doesn't calculate balances automatically and optionally allows posting manual "Balances".

Handling Advances can be done with transfers (TO/FROM) this "Cash Advance" account.
In Sure, the treatment differs depending on whether the account only receives manual transactions or also (or only) uses Import/Sync.

The case of manual transactions illustrates a normal accounting treatment well.

In the case of import/sync, the imported transactions will need to use the "Setting > Exclude" configuration, which removes the transaction from reports but keeps it in the account balance. It is necessary to understand what "Setting > Exclude" does, as this transaction setting has a very specific behavior.

This works for restitution/reimbursement, whether in 5 minutes or 45 days.

Manual Transactions

• I paid 900, where 600 is a friend's responsibility:

  • My expense is 300, I advanced 600 to the friend.

  • Sure expense:

    • Expense transaction 300

      • Post only my Categorized expense.

    • Transfer 600 TO Cash Advance.

      • Grants the advance to a friend.
      • Reduces the checking account balance. Does not appear in reports.

    • Optional: Post "New balance" 600 (or other appropriate value) in Cash Advance.

      • Updates the net worth report.

  • Sure receipt (it is not income and should not appear in reports).

    • Transfer 600 FROM Cash Advance.

      • Refund of the advanced to a friend.
      • Increases the checking account balance. Does not appear in reports.

    • Conditional: If receipt is different from 600 (+/- 1):

      • Create a new transaction with the "Extraordinary" category.
      • Income 1; or Expense 1: Categorized.

    • Optional: Post "New balance" 0 (or other appropriate value) in Cash Advance.

      • Updates the net worth report.

Imported/Synced Transactions

Imported/Synced transactions must be excluded via "Setting > Exclude" and everything must be re-entered manually.

• I paid 900, where 600 is a friend's responsibility:

  • Summary: Imported/Synced transaction 900:

    • My expense is 300, with 600 being an advance to the friend.

  • Sure expense:

    • Import/Sync Expense 900 -> "Setting > Exclude":

      • Removes from reports. Remains in the account balance.

    • Transfer 900 FROM Cash Advance.

      • Offsets the effect of the Import/Sync transaction on the account balance.6

    • Expense transaction 300

      • Post only my Categorized expense.

    • Transfer 600 TO Cash Advance.

      • Grants the advance.
      • Reduces the checking account balance. Does not appear in reports.

    • Optional: Post "New balance" 600 (or other appropriate value) in Cash Advance.

      • Updates the net worth report.

  • Sure receipt (it is not income and should not appear in reports).

    • Import/Sync Income 600 (or 599, 601) -> "Setting > Exclude"

      • Refund of the advance.
      • Removes from reports. Remains in the checking account balance.

    • Conditional: If Income is different from 600 (+/- 1):

      • Create a new transaction with the "Extraordinary" category.
      • Income 1: Categorized (or Expense 1).
      • Transfer 1 TO Cash Advance (or FROM Cash Advance).
        • Nullifies the "Extraordinary" transaction in the account balance. Does not appear in reports.

    • Optional: Post "New balance" 0 (or other appropriate value) in Cash Advance.

      • Updates the net worth report.

[Zeor-Xain]

Sure's (current) architecture offers Account Types which can be Assets or Debt/Liabilities.
It also offers transaction types Expense, Income, and Transfer, which require positive values.

It seems to me that Sure's (current) architecture, using Asset/Debt account types similar to a simple conventional accounting model, is consistent with the prohibition of negative transaction values.

However, unlike a traditional accounting model, Sure aims to provide convenience through the Import/Sync transaction feature.
This forces the system to handle externally originated transactions that cannot/should not be altered, to avoid the risk of "messing up" future Import/Sync processes.

To address these two requirements, adding a feature based on transaction grouping/splitting is quite convenient.

The difference between grouping or splitting transactions is the starting point:

• Grouping (N:1): multiple existing transactions > one group
• Splitting (1:N): an existing transaction becomes a group > creates new sub-transactions

You can think of a "split" as "reverse grouping".

considerations

Relevant technical properties:

• Monetary decomposition: The value of the grouping transaction is distributed among the splits, maintaining the sum of the splits = total value (mathematical invariant).
• Attribute polymorphism: Each split can have its own metadata (expense/income, category, merchant, notes, tag). This allows for semantic heterogeneity within the same financial operation.
• Cardinality flexibility: Supports everything from atomic transactions (no splits) to N-ary decompositions.

Expected use cases:

• Mixed transactions (part expense/part income)
• Expense allocation across different categories
• Transfer operations between accounts with fees
• Purchases with multiple items from distinct categories

[Zeor-Xain]

I asked Claude about recommended approaches for implementing splits/grouping in Sure.

This was the result:

Approach	Complexity	Time	Flexibility	Performance	Recommendation
Event Sourcing	Very High	6-8 months	⭐⭐⭐⭐⭐	⭐⭐⭐	❌ Overkill
Line Items	Medium	4-6 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	✅ BEST
JSONB Embedded	Low-Medium	2-3 weeks	⭐⭐⭐⭐	⭐⭐⭐⭐	⚠️ MVP only
Double-Entry	Very High	6-12 months	⭐⭐⭐⭐⭐	⭐⭐⭐	❌ Too complex
Allocation Table	Medium	3-5 weeks	⭐⭐⭐⭐	⭐⭐⭐⭐	✅ Good alternative
Composite	Medium-High	6-10 weeks	⭐⭐⭐	⭐⭐⭐⭐	✅ Works well

Final Recommendation: Line Item Pattern

• ✅ Clean separation of concerns
• ✅ Easy to test
• ✅ Excellent performance with correct indexes
• ✅ Does not break existing transactions (they can remain as 1 line_item)
• ✅ Intuitive for Rails developers

The Line Item Pattern is very common in e-commerce.

---

Considering that the Line Item Pattern requires the creation of a new table, I asked for recommendations on approaches related to optimizing storage.

This was the result:

Approach	Storage Overhead	Code Complexity	Query Complexity	Recommendation
Pure Line Items	+25% (always)	Low ⭐⭐⭐	Low ⭐⭐⭐	⚠️ If storage doesn't matter
Hybrid Model	0% (simple) / +25% (splits)	Medium ⭐⭐	Medium ⭐⭐	✅ BEST
STI	0% (simple) / +25% (splits)	High ⭐	Medium ⭐⭐	❌ Avoid
Nullable FK	+25% (always)	Low ⭐⭐⭐	Low ⭐⭐⭐	✅ If queries > storage
Lazy Migration	0% initial → gradual	High ⭐	High ⭐	⚠️ For MVP only

Yes, pure Line Items duplicates records. But:

• 50 MB extra for 1 million transactions is irrelevant in 2025
• PostgreSQL handles this easily (even on a Raspberry Pi)
• The gain in flexibility/simplicity far outweighs the cost

HOWEVER, if you want to optimize to the max:

• Use Hybrid Model (0% overhead for 95% of transactions)
• Accept the extra complexity of bifurcated logic

For Sure.am specifically:

• Average user: ~1,000 transactions/year
• 10 years: 10,000 transactions
• Overhead: ~500 KB

It is negligible.

Final Recommendation: Pure Line Items Pattern.

[jjmata]

@Maistho care to elaborate?

[jjmata]

This is great analysis, @TzuH-Hsu ... thanks for spending your Claude tokens on it! ;-)

Have you been working on any of it? Did you like the "Pure Line" yourself?

[jjmata]

Though having an LLM estimate 4-6 weeks makes me think how it's just next-token-predictor making shit up!

[Zeor-Xain]

Hey @jjmata,

To be honest, after I got the prompt response, I chatted a bit more with the LLM to work on a "briefing," but nothing's PR-ready yet.
I went with the ML recommendation, "Pure Line Item."

Two main hurdles:

• The database change is subtle but pretty key.
• Handling the UI/UX without touching what's already there to avoid breaking anything, which is why I'm adding new forms.

I think I'm gonna go for it, maybe shoot for an MVP. Possibly something behind an "experimental" feature flag.

I can't really commit to any hard deadlines, but I can keep at it in "lazy mode". Lemme know what you think. Is it worth me chipping away at this, even if I can't commit to a set date?"

[jjmata]

Yeah, this is a big one ... don't rush and we can definitely put it behind a feature flag!

[Zeor-Xain]

For a UI/UX MVP, I think the split/grouping feature could revolve around transaction selection.

When a transaction is selected, a floating options bar is currently displayed.

This existing toolbar can have the necessary options added:

• Split: when 1 transaction is selected
• Group: when 2 or more transactions are selected.
• Ungroup( Unsplit): When one or more "split" type transactions are selected.

I asked Nano Banana to create a UI/UX idea for the transaction list.
This is the result:

I think icon can be better:

---

Claude had another idea:

[m42cel]

A grouping approach would also make sense from my point of view. It's similar to linking two transactions in a transfer, only that it links multiple transactions together, leaving only the excess as expense or income.

This grouping would also allow to consider multiple expenses as one (e.g. paying something partly in cash and partly with card).

[jackalopes]

Adding another concrete use case here, since I ran into this from a
slightly different angle.

I do occasional reimbursable purchases on someone else's behalf, and
get paid back in one lump sum that covers both the reimbursement and
a separate fee for my time. So I end up with a single incoming
payment that really belongs to two different categories.

I went looking for a way to split that income transaction the same
way you can split an expense, but the split option only seems to
show up on expense-type transactions in 0.7.3. Wanted to flag that
as another angle on this — even just extending split to work on
income the same way it does on expenses would go a long way for
cases like mine, separate from the bigger netting/reporting
discussion above.