Training and course providers on Acumatica run into a problem that isn't about billing at all — it's revenue recognition. A cohort-based course sold as one upfront payment but delivered over eight weeks cannot be recognized as revenue the day the invoice is raised; recognizing it over the delivery period is both the correct accounting treatment and, for anyone selling multi-session or subscription-style training, often a real compliance requirement, not a nice-to-have.
Deferred revenue over the delivery window
Each cohort or course offering models well as a Project with a defined start and end date, and Acumatica's Projects module can apply percent-complete-based revenue recognition rules across that period rather than recognizing the full contract amount on invoice date. The billing event (customer pays, often upfront) and the recognition event (revenue posts to the P&L) are deliberately decoupled — cash hits the bank and a Deferred Revenue liability account on day one, and recognition posts week by week (or session by session) as the course actually delivers.
Course: "Acumatica Fundamentals" Cohort — 8 sessions, $2,400/seat
Invoice on enrollment: $2,400 -> Cash / Deferred Revenue (liability)
Recognition schedule: $300 recognized per session delivered
(8 x $300 = $2,400, spread across the
Project's task/session structure)
If a student drops after session 3:
Recognize the 3 delivered sessions,
refund or credit the remaining 5 —
handled as a billing adjustment, not
a silent write-offSessions as Project Tasks, not line items on one invoice
Structuring each session as a Project Task (rather than the course as one undifferentiated blob) is what makes the recognition schedule and the drop/refund handling above tractable — recognition posts as tasks complete, and a mid-course withdrawal has a clean boundary (sessions delivered vs not) instead of a manual proration someone has to calculate by hand.
Instructor cost and course-level margin
Instructor pay — whether staff or contracted per-session — codes against the same Project/Task structure as any professional-services cost, giving a per-cohort margin view (fees collected vs instructor cost, venue/platform cost, materials) the same way a consulting engagement gets budget-to-actual. This is genuinely useful for a training business deciding which course topics or formats are actually worth running again.
A single corporate client buying 20 seats for their team is one Customer, one invoice, but the revenue recognition and attendance tracking still needs to happen per seat/per session if partial attendance or substitutions are allowed. Model the seats as sub-lines or a linked child record under the Project rather than a flat quantity-20 line, or per-seat completion tracking becomes a spreadsheet exercise outside the system.
Wrapping up
The distinguishing problem for a training business isn't billing — it's getting deferred revenue recognition right over the delivery window, and that falls out naturally once each cohort is a Project and each session is a Task. Skip that structure and you're back to manual journal entries every close to fix revenue recognized too early.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.