How to Invoice So a Manager Can Pass It Through

Why this matters

A property manager almost never pays your invoice with money that belongs to them. They code it to a property, charge it against an operating budget or a reserve, and in many cases rebill it to an owner or a board. Your invoice is an input to a bookkeeping routine you never see. When it fits that routine it clears on the next payment cycle. When it does not, it goes to a pile the manager works when they have time, which is never, and you find out six weeks later that nothing was wrong with your work and nothing was wrong with your price. The document was simply unusable as a bookkeeping entry.

This is a different problem from justifying the spend. Justification is about whether the money should have been spent. Pass-through is about whether the entry can be made at all. A perfectly justified invoice that cannot be coded to a unit sits just as long as an overpriced one.

Step 1: Collect the coding fields before you send the first invoice

Ask for these in writing during onboarding, not after the first invoice bounces:

• Property identifier. Their code for the building, which is often not the street address.
• Unit or common-area identifier. The format matters. Their system may want 112 and reject Apt 112.
• Work order or authorization reference. The number their system generated when they dispatched you.
• Expense category expectation. How they expect this kind of work to be classified in their books.
• Submission channel. A vendor portal, a dedicated intake address, or the manager's own inbox. These pay at different speeds.
• Cutoff dates and payment terms. When accounts payable closes each cycle and how long after close a check or transfer is issued.

Skipping this step is the single most common reason a good shop ages badly on a portfolio. Nothing about your work is in question. You are simply handing over a document their system cannot swallow, over and over, and calling it a payment problem.

Step 2: One authorization, one invoice

Never combine two work orders on one invoice, even when the same tech did both on the same trip. Each work order carries its own approval, and in many portfolios its own budget line and sometimes its own owner. An invoice covering two authorizations cannot be partially approved. If one line is queried, the entire document waits.

The reverse discipline matters too. Do not split one authorization across two invoices because the parts arrived late. Issue one invoice when the work order is complete, or issue a progress invoice that says so in the reference line, so the approver knows a second document is coming and does not close the work order early.

Step 3: Split a visit that crosses units or properties at the line level

Techs work by trip. Property accounting works by unit. Those two facts collide on every multi-unit visit, and the invoice is where you reconcile them.

Record labor against the unit where it was performed, to the tenth of an hour, not spread evenly because it is tidier. Spreading is how a routine turn ends up carrying an hour of somebody else's emergency, and it is the number an owner queries a year later when they compare two units.

Travel is the line that gets kicked. Agree the rule in advance and write it on the invoice: one trip charge per visit, applied to the first work order, with a note on the other documents that the trip was shared and charged once. A per-work-order trip charge on a single-trip multi-unit visit reads as padding to an approver whether or not you intended it that way, and once one line is queried the whole batch slows.

Step 4: Put their reference where their system reads it

Portals and accounting systems match on a specific field. Their work order number belongs in your invoice reference or purchase order field, not buried in the description. If a manager has to open the document and read prose to find the number, they are doing data entry on your behalf, and the invoices they do that for are the ones that wait.

Your own job number can stay on the document. It should never be the only number on it.

Step 5: Classify the work in their budget language

Property books usually distinguish routine maintenance from unit turnover from capital work, and the three follow different approval paths and draw on different money. Routine repair typically clears at the manager's own limit. Turnover work is often charged against a specific make-ready budget with a per-unit ceiling. Capital work draws on reserves and frequently needs owner or board sign-off regardless of size.

Say which one your invoice is, in plain words, on the document. When a compressor replacement is coded as routine repair it fails at whatever level checks reserve draws, and the rejection reason never mentions your work. When a filter change is coded as capital it fails a materiality test on the other side. Neither is your judgment call to hide; you know what you did, so name it and let their system route it.

Step 6: Name the attachments the way the file will be searched

Photos, meter readings, a signed work authorization and a parts receipt are evidence. They are only useful if they can be found later, and later means eighteen months from now during a dispute with an owner, by someone who was not there.

Name every file with the work order reference, the unit, and what it shows: WO48812-unit112-before beats IMG_4471. Attach evidence to the invoice itself rather than sending it in a separate message, because portals archive the invoice and lose the email thread.

Step 7: Submit on their channel, ahead of the cutoff, and log it

Send to the channel they specified, even when the manager personally would rather you text it to them. The manager is not the payer. Log the submission date, the channel, and the confirmation reference in your own system the same day.

Cutoffs compound. If accounts payable closes on the 10th and the 25th and pays 30 days after close, an invoice that misses the 10th by one day does not lose one day. It waits for the 25th, so a one-day slip costs about half a month of aging before the 30-day clock even starts.

Worked example: one afternoon, four billable documents

A tech spends an afternoon at a 24-unit property. On site: 4.5 hours total, plus 0.6 hours of travel from the previous job.

• Unit 112, tenant-reported fault, work order issued that morning: 1.5 hours
• Unit 118, separate work order issued the previous week: 1.0 hour
• Unit 204, return visit on the shop's own prior work, inside warranty: 0.8 hours
• Common-area item found during the walk, no work order, approved verbally on site by the maintenance supervisor: 1.2 hours

That totals 4.5 hours, which matches the time on site.

What gets issued. Three invoices and one no-charge service record. Unit 112 carries its 1.5 hours plus the single 0.6-hour trip charge. Unit 118 carries 1.0 hour with a note that the trip was shared and charged once on the other work order. Unit 204 is a zero-charge document, still issued, because the unit history has to show that a return visit happened and that the shop absorbed it; an absent record reads later as an unexplained gap. The common-area item cannot be invoiced against nothing, so before billing you ask the supervisor to open a work order and you attach their emailed confirmation of the verbal approval to that fourth invoice.

What happens if you skip the split. Submitted as a single 4.5-hour invoice referencing "various units," the document cannot be coded, so it enters the research pile. Worse, the 0.8 warranty hour is invisible inside the total, so it reads as billable. That is the line an owner questions at review, and the query freezes the whole invoice, not the 0.8 hours.

What it costs in cycle terms. With cutoffs on the 10th and the 25th and payment 30 days after close, the split batch submitted on the 8th clears on the first cycle. The unsplit version comes back for re-issue, is re-submitted on the 14th, and pays on the second cycle. Same work, same price, roughly half a month later, for a reason that has nothing to do with the work.

When one bounces, never edit and resend the same number

An invoice that comes back for a coding correction feels like a small fix, so the instinct is to change the field and send it again under the same number. Do not. Most vendor portals and accounting systems run duplicate detection on the invoice number, and a second document arriving under a number already in the system is either rejected outright or, worse, silently matched to the first record so your correction never lands.

The correct sequence is: issue a credit against the original number, issue a new invoice with a new number, and put a one-line cross-reference on the new document naming the credited original. That gives the manager a clean audit trail, which is what they need if anyone asks later why two documents exist for one visit, and it keeps your own aging report honest, because the original stops showing as open.

Then reset your expectations on timing. A re-issued invoice starts a fresh cycle from its own submission date. It does not inherit the age of the original, however unfair that feels, so a re-issue in the second half of a period usually costs a full cycle rather than a few days.

Chase the payer, not the manager, and know when to switch

The manager authorized the work. Accounts payable pays for it. Those are usually different people and often different companies, and shops waste weeks asking the first one about the second one's job.

A workable escalation, once an invoice has passed one full cycle past its terms: confirm receipt with accounts payable directly on the channel you submitted to, referencing the submission confirmation you logged in step 7. If that produces nothing within a week, go to the manager, but ask a specific question rather than a general one. "Can you confirm work order 48812 was approved on your side and released to AP" is answerable in one line. "Any update on our invoices" is not, and it will sit.

Keep the two questions separate in your own tracking as well. An invoice waiting on approval is a scope or documentation problem you can fix. An invoice approved and waiting on payment is a cash-cycle problem you cannot, and it is the one that decides whether the account fits your terms at all.

How to verify you got this right

Measure per account, on the last 20 invoices you submitted to it, not on your overall aging:

• Count how many required a re-issue or a correction of any kind.
• Count how many were paid on the first payment cycle after their submission date.

The gate: if more than 2 of 20 needed a re-issue, OR more than 3 of 20 missed their first cycle, your coding fields are wrong rather than your work. Both conditions are independent triggers, so either one alone is enough to act on. Fix one field at a time, starting with whichever appears in the most rejection notes, and re-measure at the next 20 invoices rather than at the next month. Changing three fields at once means you learn nothing about which one was the problem.

Run the example above through that gate. If the unsplit multi-unit invoice is a habit rather than a one-off, a portfolio doing four such visits a month puts four re-issues into every 20 invoices, which clears the 2-of-20 trigger on its own and points straight at the unit-level split as the field to fix first.

References

• See related: What a Property Manager Needs to Defend a Spend
• See related: The Multi-Property Work Order SOP
• See related: How to Invoice the Same Day the Work Is Done
• See related: What Makes an Invoice Easy to Approve