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.
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.
When to allocate and when not to
| Situation | In TidyOne | Avoid |
|---|---|---|
| The invoice belongs to one beneficiary only | One expense with Beneficiary + Case. Do not enable the split. | Do not create unnecessary allocations. |
| The invoice is shared by several people | One expense + “Split the amount between multiple beneficiaries”. | Do not copy the invoice or duplicate the payment. |
| The supplier issued separate invoices | Use 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 basis | Keep 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.
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:
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.
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.
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.
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
Checklist before sharing the report
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
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 freeThis 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.