A freelancer can finish a project, issue an invoice and still struggle to explain what the month produced. One client pays promptly, another pays in stages, and a platform sends a combined payout with deductions. Garnered could be the name of a practical tool that gathers those pieces into a view the user can inspect. Its value would come from making the trail understandable, rather than presenting a confident number with unexplained assumptions.
This is an illustrative product concept, not an existing financial service. The first version could serve independent creative professionals who invoice several clients and receive occasional marketplace payouts. Keep the job narrow: connect completed work to expected payment, record what arrived and show the items that need attention. Tax calculations, investment recommendations and regulated services would require separate consideration beyond this concept.
Begin with reconciliation
The first screen should answer a specific question: which expected payments have not been matched? A user could add an invoice manually, import a file and assign incoming payments to the relevant work. The record would keep the original amount, the amount received, any recorded fee and the remaining difference. Every calculated total should be traceable to the underlying entries.
For an early prototype, a manual import may be enough to test whether the workflow helps. Banking connections introduce another set of design, access and security decisions. There is little reason to solve those before learning whether customers understand the matching process. A clickable prototype and a small collection of invented transactions can expose confusing labels without handling anyone's real account information.
Design around a messy example
Consider a hypothetical illustrator with three invoices. One client pays the full amount, one sends a partial payment, and a marketplace payout covers two jobs after a fee. A useful system would allow the partial payment to leave an open balance and the combined payout to be split across jobs. It would not silently mark all three invoices as paid because money appeared in the same week.
Give the user a place to explain differences. A fee, a refund and a currency adjustment are different events. Even if the first version stores them simply as labeled adjustments, the distinction helps the person reviewing the account. Include an undo action and a visible history so that fixing a mistaken match feels ordinary rather than risky.
Separate observation from planning
Users may want a reserve category for future commitments. The interface could let them create a self-chosen allocation and label it clearly as their own planning choice. It should not imply that a generic percentage is the correct tax amount for every freelancer. A product team would need qualified review before offering consequential tax guidance or making jurisdiction-specific claims.
The same care applies to forecasts. Expected payments and received payments should have separate headings, with dates and statuses visible. A planned project is different from an issued invoice. An issued invoice is different from money received. Mixing them into one large earnings number would undermine the product's most useful promise: clarity about what the records actually show.
Make the first offer understandable
The initial offer could be a paid workspace for one person, built around a limited number of imports and straightforward exports. Before setting a price, test what the customer currently does and what problem is worth paying to remove. Some people may only need a spreadsheet. Others may need collaboration with a bookkeeper. Those are different customer situations and should not be hidden behind a general pitch to every freelancer.
A sensible onboarding flow would ask the user to reconcile a small period first. Let them see a successful match, an unresolved difference and an export before asking them to reorganize years of records. An explanation beside the first confusing entry may help more than a long introductory tour. Support requests from this stage would be valuable product research.
Reach people where the work happens
A focused distribution path would be partnerships with freelance communities and practical tutorials showing the reconciliation workflow. The examples should use clearly invented records. A short demonstration of splitting one payout into two jobs can tell a prospective customer more than a page full of claims about financial freedom.
The product could also offer an import template that people use independently. If the template exposes a recurring frustration, it creates a natural reason to consider the software. Measure completion of the actual task: did someone match their entries and identify a discrepancy? Downloads alone would not establish that the tool helped.
Build trust into the records
Security and data handling would need deliberate design before collecting real financial information. The team should decide which records it needs, who can access them, how deletion works and how exports remain available. Those choices belong in the product architecture and customer explanation, rather than being added as vague reassurance after launch.
Start the next round of research with five freelancers who receive more than one kind of payment. Ask them to walk through a recent month using their own existing method, with private details withheld. Look for the steps they repeat, the differences they cannot explain and the points where they ask another person for help. Garnered.com is available for acquisition if that is the kind of useful, focused product a buyer wants to build. The Domain Details form provides a place to discuss the domain and the proposed direction.