Translation and localization agencies are a narrower variant of the staffing/consulting pattern: work is billed to the client (usually per word, sometimes per hour or per project), delivered by a large pool of freelance linguists paid per word or per hour, and margin depends on the same pay-and-bill spread problem staffing firms have — just priced per word instead of per hour, which changes the unit but not the underlying architecture.
Per-word billing is a rate table problem, not a special feature
"Per word" billing is not natively modeled as a distinct unit in Acumatica, but it doesn't need to be — it's a unit-of-measure and rate configuration on the Project Task, the same mechanism used for any non-hourly billing unit. A translation job is a Project Task with a quantity (word count) and a rate ($ per word, varying by language pair and often by translator skill tier), billed as a fixed quantity-times-rate line rather than time-and-material hours.
Task: Translate Manual — EN to French (Canada)
Quantity (UOM = WORD): 14,200
Client Rate: $0.14 / word = $1,988.00 billed
Linguist Pay Rate: $0.06 / word = $852.00 cost (AP, per-project vendor bill)
Spread: $0.08 / word = 42.9% margin on this task
Language-pair rate variance handled via a rate table
keyed on (SourceLang, TargetLang, SkillTier), not
hardcoded per project.The linguist pool is a large, high-turnover AP vendor base
Freelance translators are best modeled as Vendors, paid via AP against the Project/Task once a job is marked delivered and (usually) reviewed. The operational challenge is volume and churn — an agency may work with hundreds of freelancers, most doing occasional jobs — so vendor onboarding needs to be lightweight (a self-service vendor setup form feeding the REST API rather than manual AP vendor entry for every new linguist) or the AP team becomes the bottleneck on every new job.
CAT tool / TMS integration is the real system boundary
Actual translation work happens in a translation-management system or CAT (computer-assisted translation) tool (memoQ, Phrase, XTM, etc.), which tracks word counts, fuzzy-match discounts (a segment that's 95% similar to a previously translated segment bills at a reduced rate), and delivery status. Acumatica should not try to replicate that — the integration boundary is: job delivered and word-count-with-fuzzy-adjustments confirmed in the TMS triggers the Project Task quantity and both billing and vendor-cost lines in Acumatica via the API, one-directional, same pattern as the ATS integration for recruitment.
A 95%-match segment usually bills the client at a reduced rate — but the linguist reviewing it is also typically paid a reduced (not zero) rate for the touch-up work. If the integration only adjusts the client-billed quantity and not the vendor-cost quantity, margin reporting silently breaks on every job with fuzzy matches, which in practice is most jobs. Confirm both sides of the word-count adjustment are mapped before trusting the margin report.
Wrapping up
Translation billing is a per-word rate-table variant of the standard Projects billing pattern, with the linguist pool modeled as high-volume AP vendors. The integration work with the CAT/TMS tool — and specifically making sure fuzzy-match quantity adjustments hit both the client bill and the linguist pay side — matters more to getting accurate margin than anything on the Acumatica configuration side alone.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.