Skip to content
TidyOne
NONPROFIT · MULTI · SHARED EXPENSES

Shared invoice / expense → Beneficiaries → Allocation → Document → Report

How to keep one real payment, split the cost across several people and verify the supporting invoice in reports.

18–22 min read · Updated 24 September 2026
At a glance

When one invoice or payment belongs to several beneficiaries, keep one expense matching the real payment, attach the supporting document to that transaction, and use “Split the amount between multiple beneficiaries” to allocate the cost exactly. TidyOne keeps the invoice linked to the shared transaction, while a beneficiary report can use only that person’s allocation without duplicating the document value.

Invoice / payment→One expense→Allocations→Linked document→Report

Why a shared invoice should not be copied for every beneficiary

A nonprofit supporting several people may receive one invoice for transport, accommodation, group therapy, supplies or another shared service. For example, a supplier issues one 900 RON invoice for two people and the organization pays it once. If you enter the same invoice twice — 540 RON for one beneficiary and 360 RON for the other — the per-person totals may look right, but the financial record no longer mirrors reality: the bank and supplier show one payment and one source document.

TidyOne separates the real transaction from the internal cost allocation. The transaction keeps the original amount, currency, project, fund and supporting document; allocation rows keep the amount belonging to each person or case. The same principle applies to shared donations, but this guide focuses on expenses.

An invoice is not automatically proof of payment.An invoice shows what was billed. If a report must show that the amount was actually paid, compare the TidyOne entry with the bank statement, receipt or other payment evidence required by your accountant or funder.

When to allocate and when not to

Choose the structure that reflects the real event
SituationIn TidyOneAvoid
The invoice belongs to one beneficiary onlyOne expense with Beneficiary + Case. Do not enable the split.Do not create unnecessary allocations.
The invoice is shared by several peopleOne expense + “Split the amount between multiple beneficiaries”.Do not copy the invoice or duplicate the payment.
The supplier issued separate invoicesUse separate expenses for the separate real invoices/payments.Do not merge distinct documents into a fictional transaction.
The shared cost cannot yet be allocated on a defensible basisKeep it at project/fund level and postpone the individual allocation.Do not invent percentages simply to make reports look complete.

Allocation does not decide who is entitled to funding and it does not approve expense eligibility. It is an operational record. For grants or restricted funds, the allocation method must follow the funding agreement, applicable rules and the organization’s accounting policy.

Before recording: verify people, cases and the allocation basis

In the Association / nonprofit workspace with multiple beneficiaries, make sure the relevant people already exist in Beneficiari & Cazuri (Beneficiaries & Cases). If the allocation is case-specific, each case must belong to the correct person. TidyOne validates that relationship at save time and rejects a case belonging to a different beneficiary in the same allocation row.

Then establish the allocation basis. It could be nights stayed, kilometres travelled, therapy hours, quantities supplied, a project-approved share or another documented measure. If a 900 RON invoice represents three sessions for Anna and two for Radu, a proportional split may be supported by that record. If there is no defensible basis yet, do not turn an estimate into a false “exact” number.

Keep the rationale.Use the Note field for a short explanation such as “60/40 allocation per transport log 18 Sep”. Keep the underlying evidence separately when required.

Step 1 — In Finance, create one expense

Open Financiar (Finance) and choose + Cheltuială (+ Expense). In Furnizor / beneficiar plată, enter the supplier or payment description. If you have a supplier contact, you can associate it as well.

Enter the exact total of the real transaction, its currency, category, subcategory, date and note. If the bank shows 900 RON paid, the transaction amount is 900 RON — not 540 and not 360. If the invoice and payment are in EUR, keep EUR. TidyOne keeps currencies separate in reports rather than silently converting them.

For a shared cost, do not pick one beneficiary as though the entire amount belonged to that person. Use allocation rows in the next step.

Step 2 — Enable the multi-beneficiary split

Tick “Împarte suma între mai mulți beneficiari” (Split the amount between multiple beneficiaries). In Alocarea sumei, add a beneficiary, an optional case and that person’s amount. In our example:

Allocation example

Invoice and payment: 900 RON
Anna · Therapy: 540 RON
Radu · Therapy: 360 RON
Total allocated: 900 RON · Difference: 0 RON

TidyOne calculates the allocation total and will not save the split unless the rows add up exactly to the transaction amount. Every row needs a beneficiary and a positive amount. If a case is selected, the application validates that it belongs to the beneficiary in that same row.

When the split is enabled, TidyOne clears the single Beneficiary/Case fields on the main transaction. Individual ownership is stored in the allocation rows instead. That is intentional: the 900 RON payment is shared, while 540 and 360 are the two beneficiary perspectives on that one expense.

Step 3 — Choose a project and fund only if they apply to the whole expense

You may link the transaction to a Project and Fund. In the current product, those fields belong to the whole transaction. Allocation rows do not have their own project or fund. A shared invoice therefore works best when all shares belong to the same project and fund.

If 540 RON must contractually be reported to Fund A and 360 RON to Fund B, one split transaction cannot fully represent that fund-level separation. Do not automatically invent two bank payments if the statement shows only one. Preserve the real evidence and agree the accepted reporting treatment with the accountant or funder.

Current project-filter limitation.To verify an exact beneficiary/case allocation, use the beneficiary report with Project → All projects. The current report logic applies allocation rows when a beneficiary/case filter is present and no project filter is active. Adding a project filter can leave the original transaction amount in scope instead of the allocated share.

Step 4 — Attach the invoice or evidence to the same transaction

The expense form includes Dovadă / document (Evidence / document). Choose the relevant invoice, receipt or payment proof as an image or PDF. The current attachment limit in this form is 15 MB. On save, the file is also added to Documents and linked to the transaction.

This link matters for reporting. TidyOne treats an expense as having supporting evidence when a document is actually linked to its transaction. For a split expense, the shared invoice remains one piece of evidence for the original transaction. You do not need to upload the same invoice once for Anna and once for Radu.

With the split enabled, the main transaction has no single beneficiary/case, and an attachment created from that form inherits that same absence of one individual owner. That does not break beneficiary reporting: the report can include the document because it is linked to the transaction selected through the allocation.

What if you started with Scan invoice / document and AI?

The AI scanner can read issuer, date, total and line items, and it can propose a beneficiary, case, project or category. However, the current AI review flow has one Beneficiary and one Case for the document and the financial transactions it creates. It does not create transaction_allocations rows.

So for an invoice that must be split across several beneficiaries, do not assume that selecting one person in AI review creates the allocation. If AI confirmation has already created financial expenses, inspect those entries before adding a manual shared expense; otherwise you can count the same invoice twice.

The clearest current workflow for a shared invoice is to start from Finance → + Expense, create the allocation and attach the source document there. If you use AI as a reading aid, treat its output as a proposal and make sure it does not create another financial record for the same payment.

Documented product limitationTidyOne does not yet provide a single combined “AI invoice review + multi-beneficiary split allocation” step. This tutorial uses the existing path that preserves one real transaction and explicit allocations.

Step 5 — Save and verify the transaction in Finance

After saving, Finance shows the transaction once. When allocations exist, the row includes “Împărțită: N beneficiari” (Split: N beneficiaries). If a file was attached, it also shows “Document atașat”. This is a quick check that you did not create two expenses for one invoice.

If you later edit the transaction, TidyOne reloads its existing allocation rows. Changing the total means the allocations must also be updated because they still need to equal the transaction amount. If you select another file while editing, the application warns that another document will be added to the archive; do not treat that as an automatic replacement of the existing invoice.

Step 6 — Verify each beneficiary’s share in the Beneficiary / case report

Open Reports, choose Raport beneficiar / caz (Beneficiary / case report), select the person or case and the period containing the expense. For allocation verification, leave Project → All projects and click Actualizează raportul (Update report).

The current logic looks up transaction allocations and replaces the original amount with the sum of rows matching the selected beneficiary/case. For Anna, the 900 RON expense is reported as 540 RON; for Radu, the same transaction is reported as 360 RON. In the CSV export, Reported amount, Original amount and Beneficiary allocation distinguish these two levels.

The document-quality section considers the expense documented when the document is actually linked through transaction_id. Merely having a PDF somewhere in the archive is not enough. If the invoice exists in Documents but is not linked to the transaction, the report can still list the expense under missing linked evidence.

Worked example: one transport invoice for two cases

The nonprofit supports Anna, with a “Therapy 2026” case, and Radu, with a “Recovery 2026” case. Both travel as part of a shared “Access to therapy” project. The transport provider issues one 900 RON invoice and the nonprofit pays it by bank transfer on 24 September.

The transport log supports a 60/40 allocation. The operator opens Finance → + Expense, enters the supplier, 900 RON, the correct category and payment date. They enable the split, enter 540 RON for Anna and her case, then 360 RON for Radu and his case. They select the shared project, attach the invoice PDF and add “60/40 per transport log” in the note.

Anna’s beneficiary report, with no project filter, reports 540 RON and recognizes the invoice as linked evidence. Radu’s report reports 360 RON. The project/general report keeps the 900 RON expense. There are not three payments; there are three views of one payment: the project total and the two internal allocations.

Math check

540 RON + 360 RON = 900 RON.
Anna beneficiary report: 540 RON.
Radu beneficiary report: 360 RON.
Project/general report: 900 RON.
Evidence: one PDF linked to the 900 RON transaction.

Common mistakes that distort the report

01Entering the invoice twice. One copy per beneficiary duplicates transactions and can duplicate expenses.
02Confirming AI for one beneficiary, then adding the shared expense manually. Check whether AI already created transactions first.
03A document exists in the archive but has no transaction link. The PDF alone is not automatically supporting evidence for that expense report row.
04Allocations do not equal the total. Correct the rows instead of creating a fictional balancing transaction.
05The case belongs to another person. Select the correct beneficiary; TidyOne validates the relationship.
06A project or fund is selected merely to fill the field. It must describe the whole shared transaction.
07Using Beneficiary + Project filters to verify the split. In the current version, leave the project unfiltered for the exact allocated amount.
08Treating the invoice as payment proof. Verify actual payment separately when required.

Checklist before sharing the report

AThere is one transaction for the real payment shown by bank/cash records.
BThe allocation rows add up exactly to the transaction amount.
CEvery selected case belongs to the beneficiary in that row.
DThe allocation method can be explained and, when needed, documented.
EThe project and fund apply to the entire transaction.
FThe invoice/evidence is linked to the transaction, not merely stored elsewhere in the archive.
GThe beneficiary report is checked without a project filter when validating allocations.
HThe project total and bank records are reconciled separately from internal beneficiary allocations.

Frequently asked questions

Can one invoice support two beneficiaries?

Yes, when the invoice and payment are genuinely shared. Keep one document and one transaction, then allocate the amount. Do not upload duplicate copies only to place one in each person’s record.

Does the invoice need to name the beneficiaries?

TidyOne cannot determine your legal or contractual invoice requirements. Preserve the real supplier document and use internal allocations only when the organization has a defensible basis for them.

Can I split an expense without selecting cases?

Yes. The case is optional in an allocation row; beneficiary and amount are the key fields. Use a case when you need more precise reporting for a distinct need.

Can one shared expense be split across different funds?

Not through the current allocation rows. Project and fund are fields on the entire transaction, not on each beneficiary share.

Can AI calculate the split automatically?

Not in the current flow. AI can extract document data, but the allocation decision and its rationale need human verification. AI confirmation does not create multi-beneficiary allocation rows.

Why does my report show 900 RON instead of 540 RON?

Check whether a project filter is active. For a transaction with allocations, exact beneficiary/case scoping is currently applied when no project filter is present. Set Project to All projects and refresh the report.

Why is an expense listed as missing a document when the invoice exists in Documents?

Because the report checks whether the document is linked to that transaction. An unlinked PDF in the archive is not automatically treated as the evidence for that expense.

What to read next

Start from the real transaction.

If the bank shows one payment, build around that payment: one total, one source document, then beneficiary allocations. That keeps the general report and individual reports reconcilable.

Get started free

This tutorial describes the TidyOne logic available in the V13.5.23 project reviewed on 24 September 2026. Examples are fictional. It does not replace statutory accounting, funding agreements or legal/tax advice.