Two numbers, two decisions, and why collapsing them into one is where the trouble starts.
Most of the time it's just me on a project. But every so often something comes up that needs a specialist I'm not, and I bring in a subcontractor for a piece of the work. The first time that happened, I realized I hadn't actually thought through how the money should move — and it's a more common trap than people expect.
The obvious approach is: the subcontractor tells you what they charged, you add your markup, and that becomes both the client invoice line and what you owe the subcontractor. One number, two jobs. It feels simple right up until it isn't — usually the moment you want to mark something up for the client without also handing the subcontractor a raise they didn't ask for, or the moment a subcontractor's reimbursable expense (a flight, a licence, a part) gets inflated by your markup logic before it ever reaches their payout.
The fix is to stop treating "what the client owes" and "what the subcontractor is owed" as the same number wearing two hats. They're two separate decisions that happen to be based on the same piece of work:
Once you separate those, a lot of the confusion disappears. You can mark up an expense for the client by 20% without the subcontractor ever seeing a different reimbursement number. You can pay a subcontractor a flat rate for a line item that you bill the client hourly for. The two numbers just don't have to agree, because they're answering different questions.
This is the reason Bizily treats a line item or expense's billable amount (what the client sees) and its compensation status (whether it counts toward what a worker is owed) as two independent settings, not one derived from the other. You decide separately whether something is billable to the client and whether it's compensable to the worker who logged it. Marking up a client price doesn't change a subcontractor's payout, and paying a subcontractor for something doesn't force it onto the client's invoice.
It's a small distinction on paper, but it's the difference between running payroll and client billing as one tangled process, or as two calculations that happen to share the same source data.
