Skip to content
Skip to content

Allocate Compute costs to your team

How to assign Compute costs to your own teams and projects while the invoice total stays the same.

Updated

Start with the conserved total

Synthetic internal-allocation example: divide a USD 100.00 expense into USD 60.00 for one project and USD 40.00 for another. The two allocations conserve the original USD 100.00 total. They do not create two Lithi invoices, change the payment instruction or perform an automatic split. This is arithmetic only, not a transaction or an automatic split feature.

Cost allocation records which part of your organization is responsible for an expense. It does not change the amount Lithi charges or grant anyone permission to spend. Start with the correct Compute account and legal entity, then identify the cost center or project your finance team uses for that work.

For prepaid work, distinguish the credit purchase from accepted consumption. A paid purchase invoice records the prepayment; the monthly usage statement explains which work consumed it with no new amount due. Allocate the accepted consumption under your finance team's policy without booking the purchase and consumption as two copies of the same expense.

Keep the work reference, quote, invoice and allocation reference together. A project label in a spreadsheet is not a new Lithi account, and an accounting-system department does not automatically become an access boundary. Use the actual account and project model available to your team.

Choose an approved reference

The purchase-order policy distinguishes allocation kind none, cost_centre and project. Use a genuine approved reference when one is required; do not fill a missing value with a guessed department or made-up code. The referenced cost center or project belongs to your organization's accounting process, while the original Lithi account and invoice identity remain unchanged.

InformationResponsible decisionRecord to retain
Legal customerThe account's authorized billing or procurement owner confirms the responsible entity.Correct account and issued invoice identity.
Cost center or projectYour finance team supplies the approved allocation code.Allocation kind and reference.
Purchase orderProcurement confirms whether a PO is required and supplies the approved reference.The applicable PO and approval evidence.
Work approvalThe authorized work approver reviews scope and maximum spend.Quote and work-approval reference.
Accounting treatmentYour finance team chooses the expense account, tax treatment and any internal split.Approved external posting and reconciliation record.

These decisions are not interchangeable. A PO does not raise a Compute spending ceiling; a work approval does not authorize payment; an external account code does not grant access to another team's jobs.

Review the mapping before an external posting

Inspect the existing Finance sync metadata for the intended account and customer-payable direction. Compare the mapping fingerprint, legal entity, country and safe external reference with the invoice. A dry run lets you inspect the mapping; it is not evidence that an allocation or bill has been written to your accounting system.

Only transfer values actually supported by your accounting process. Do not assume arbitrary department, class, tracking-category or custom-field values synchronize automatically. Keep credentials in your customer-owned tools and obtain the separate approval required for any external posting. The finance mapping guide explains that boundary.

Reconcile totals and changes

If the allocation is missing or wrong, preserve the invoice and pause the external import until finance confirms the intended code. Correct your accounting mapping through its approved process; do not rewrite Lithi usage or invoice totals. Record the mapping revision and compare the resulting payable with the original invoice after any correction.

A successful allocation review leaves the original payable amount conserved, the responsible entity and code explained, and no duplicate expense. Continue with purchase orders when procurement approval is part of the account policy.

Was this page helpful?