Engineering documents
Bill of Materials Translation Services
We translate bills of materials so that every part carries the same name in your ERP, on your drawings, in your service manuals, and on your customs paperwork. Short, ambiguous item descriptions are resolved with your engineers, not guessed at, and SAP or Oracle field limits are respected to the character.
Translated descriptions that fit SAP's 40-character material text and Oracle item fields, delivered as clean import files with your column structure intact.
BOM terminology is locked in a termbase and enforced across your drawings, service manuals, and catalogs, so item 4711 never has two names in two documents.
Ambiguous short descriptions go back to your engineering contact as a structured query list before release, because "COVER, BRG, RH" can mean four different parts.
The BOM Feeds Every Other Document You Publish
Bill of materials translation looks like the smallest job in a documentation program: a few thousand short lines, no prose, no formatting. It is actually the most consequential. The BOM is the upstream source that drawings, spare parts catalogs, service manuals, purchase orders, and customs declarations all inherit from. Translate it inconsistently and the error multiplies into every downstream document; translate it well and half of your future documentation work is already normalized.
That inheritance is why we treat a BOM as a terminology project first and a translation project second. Each line becomes a termbase entry: source description, approved target description, part number, and context. When we later work on the manual that references item 30-0417, the termbase serves the exact approved name automatically. Clients who came to us after years of ad hoc translation often discover the same physical part carrying three names across their Spanish documentation, one from each vendor who touched it. Fixing that costs far more than doing the BOM properly at the start.
The BOM's reach extends past documentation into transactions. Distributors order from it, assembly plants pick from it, and border agents read it. Over 15 years we have translated bills of materials for automotive tier suppliers localizing production to Mexico, electronics firms onboarding Asian contract manufacturers, and machine builders whose service manual translation program depended on part names being settled first.
Short Descriptions Are the Hardest Text in Technical Translation
"COVER, BRG, RH." Nine characters of English, four plausible readings. Is BRG a bearing cover or a bridge component? Is RH right-hand or a material code? BOM descriptions are written in a compressed noun-first dialect, stripped of the articles and prepositions that normally disambiguate language, and they were composed by an engineer who had the part on the bench in front of them. The translator has only the string.
Context recovery is therefore the core skill. Before translating, we cross-reference each ambiguous line against whatever context exists: the drawing that shows the part, the assembly it belongs to in the multi-level structure, the commodity code, the supplier name. Our practice of translating engineering drawings alongside their parts lists exists partly for this reason; seeing item 12 pointed to by a balloon on the exploded view resolves in two seconds what a spreadsheet cell never could.
What cannot be resolved from context goes into a structured query list: line number, source string, the competing readings, and our recommended interpretation. Your engineer answers in one pass, usually in under an hour for a few dozen queries. That hour is the cheapest insurance in the whole project. A guessed "bearing cover" that was actually a "bushing carrier" walks straight into your Mexican plant's picking system and stays wrong for years.
SAP's 40 Characters: Translating Into a Box That Does Not Stretch
ERP systems impose hard limits that ordinary translation ignores. SAP's classic short material description (MAKTX) allows 40 characters. Oracle and most PLM systems have their own caps, and label printers downstream may truncate at 30. German compound nouns and Spanish prepositional phrases both run longer than English, so a naive translation of a 38-character description simply does not fit, and what the system silently truncates may be the load-bearing word.
We handle limits as a hard constraint, not an afterthought:
- Your export defines the cap per field, and our tooling validates every translated cell against it before delivery, so nothing arrives at 41 characters.
- We build an approved abbreviation set per language (VÁLV. for válvula, IZQ. for izquierda) and apply it consistently rather than improvising per line.
- Noun-first word order is preserved so truncated displays still lead with the part type, the way warehouse staff actually scan a pick list.
- Where a description cannot survive the cap without losing meaning, we flag it instead of silently degrading it, and propose a long-text field entry to carry the remainder.
Deliveries go out in your import format: XLSX or CSV keyed by material number, ready for LSMW or your load tool, with a validation report attached.
Multi-Level BOMs: Structure Is Meaning
A flat parts list names components; a multi-level BOM encodes how the product is built. Level 2's "HOUSING, MACHINED" is the parent of level 3's castings and inserts, and the naming must reflect that hierarchy in the target language too. If the parent assembly is translated as "carcasa" on level 2 but its child items refer to "alojamiento", the structure still loads into the ERP, but every human who reads it loses the thread.
We translate multi-level BOMs top-down: assemblies first, then their children, so parent terminology propagates. Phantom assemblies, reference designators, and quantity-per fields pass through untouched. For electronics BOMs, reference designators (R14, C203, U7) and manufacturer part numbers are locked as do-not-translate tokens by our tooling, which matters when a fatigued reviewer is scanning line 3,800 of a dense board BOM. This is standard fare in our work for electronics and semiconductor clients, where a single board can carry more distinct line items than an entire machine frame.
A BOM error compounds at roughly the rate of your document count. One mistranslated part name in a 2,000-line BOM typically reappears in the spare parts catalog, two service bulletins, the picking system, and the customs description before anyone notices. Industry post-mortems on recall logistics regularly trace weeks of delay to exactly this class of error, which is why we put independent review on BOMs despite their deceptively simple format.
Customs, HS Codes, and Descriptions That Clear the Border
When a BOM crosses a border, its descriptions stop being internal shorthand and become declarations. Customs brokers build tariff classifications from them, and vague or inconsistent wording invites inspection holds. US Customs and Border Protection expects commercial descriptions specific enough to verify the declared HS code; "PARTS" or "COMPONENTE" does not qualify, and a Spanish description that contradicts the English invoice line is worse than either alone.
For clients shipping under USMCA rules, we align translated BOM descriptions with the wording conventions their broker uses for HS classification, and we keep the English and Spanish lines verifiably parallel so origin audits read cleanly. We do not classify goods, that is your broker's licensed work, but we make sure translation never becomes the reason a classification is questioned. One automotive client, part of the wave of nearshoring programs we support through automotive translation work, had pallets held twice in Laredo because the Spanish packing descriptions had drifted from the English BOM over three years of piecemeal edits. Re-baselining the bilingual BOM ended the holds.
Keeping the BOM, the Drawing, and the Catalog in Agreement
Consistency across documents is not a byproduct of careful translation; it has to be engineered. Our mechanism is simple and strict. The approved bilingual BOM becomes the master termbase. Every subsequent project for the same client, whether it is a parts catalog, a datasheet set, or an operator manual, runs against that termbase, and our QA tooling flags any segment where a translator deviated from an approved part name. Deviations need a reason, and "it sounded better" is not one.
The same discipline applies in reverse when documents come first. If we translated your technical datasheet translation project last year and the BOM arrives this year, we harvest the established names before starting, so the datasheet and the BOM converge instead of competing. Terminology work compounds: by the third project, most of a new BOM pre-translates from memory, and you pay accordingly less.
Engineering Changes: Keeping the Translated BOM Alive
A BOM is never finished. Engineering change orders add lines, delete lines, swap suppliers, and reword descriptions, and each ECO quietly invalidates part of the translated version. Companies usually notice the drift months later, when the Spanish BOM in the Monterrey plant no longer matches the English master and nobody can say which of the 214 differences are deliberate.
We prevent the drift with a differential update service. After each ECO batch, you send the current export; our tooling compares it against the last translated baseline and isolates exactly what changed: new lines, modified descriptions, deleted items. Only the delta is translated, reviewed, and merged, and the delivery notes list every line touched, keyed to the ECO numbers you give us. Turnaround for a typical monthly batch of 50–150 changed lines is two to three business days, and the cost is proportional to the delta, not the file.
Two details make this reliable in practice. First, description rewording on the English side is treated as a change even when the part is physically identical, because the approved target name may need to follow, and that decision belongs to your engineers, not to silence. Second, deleted lines are retired from the active termbase but archived, so a part revived two years later gets back its original approved name instead of a new competing one. Document control people recognize this discipline immediately; it is their own change management, extended across a language boundary.
How a BOM Project Runs, Start to Finish
Here is the sequence for a typical engagement, using a real profile: 3,400 lines, English into Simplified Chinese, for a US equipment maker onboarding a Suzhou contract manufacturer.
| Step | What happens | Typical duration |
|---|---|---|
| Intake | ERP export analyzed, fields classified as translate / do-not-touch / validate, character caps confirmed | Half a day |
| Pre-translation | Existing termbase and reference documents harvested, repeated lines deduplicated | One day |
| Translation | Specialist translates with drawings and assembly structure on the second screen | Three to six days |
| Query round | Ambiguous lines returned as a structured list, engineer answers in one pass | Client-dependent |
| Independent review | Second linguist verifies against the termbase and character caps, per our ISO 17100-compliant process | Two to three days |
| Delivery | Import-ready file, validation report, and updated bilingual termbase you keep | Same day |
For that Suzhou project, the query round contained 41 items out of 3,400 lines. Four of the answers changed the translation materially, including one where "PLATE, WEAR" had been entered in the source BOM as "PLATE, WEAR." on some lines and "WEAR PLT" on others, two spellings the client's own ERP had accumulated for one part. The bilingual delivery merged them, and the client corrected the English side too. Work in the other direction, Chinese supplier BOMs into English, runs through our Chinese technical translation team with the same structure.
We are a Texas-based agency, ATA and GALA member, serving manufacturers across the United States, and BOMs are one of the places where that industrial focus shows most. If you are still deciding which documents to translate in what order, start here for the full map; our standing advice is that the BOM should come earlier than most companies place it.
Bill of Materials Translation: Frequent Questions
What file formats do you accept for BOM translation?
Anything your ERP or PLM exports: XLSX, CSV, XML, or direct SAP and Oracle extracts. We keep your column structure intact, classify each field at intake as translate, do-not-touch, or validate, and return an import-ready file keyed by material or item number. Multi-level structures, phantom assemblies, and reference designator columns pass through unchanged. If you can only produce a PDF report from the system, we can work from it, but a structured export is faster and removes transcription risk entirely.
How do you deal with character limits like SAP's 40-character field?
The limit is enforced by tooling, not by translator attention. You tell us the cap per field, our environment validates every translated cell against it, and nothing leaves at even one character over. To fit meaning into the box we use an approved per-language abbreviation set applied consistently, keep noun-first word order so truncated displays still lead with the part type, and flag any line where the cap genuinely cannot hold the meaning, proposing a long-text entry for the remainder instead of silently degrading the description.
Can you keep our BOM consistent with catalogs and manuals we already have?
Yes, and this is the heart of our method. Before translating, we harvest part names from your existing translated catalogs, manuals, and drawings into a termbase, resolving conflicts with your engineering contact where documents disagree. The BOM is then translated against that termbase, and it becomes the master reference for every future document. Our QA tooling flags deviations from approved names automatically, so consistency is checked mechanically on every line rather than left to reviewer memory.
What volumes can you handle and how fast?
A 3,000–4,000 line BOM in one language pair typically runs seven to ten working days including the engineer query round and independent review. Larger programs, 20,000 lines across several plants or five target languages at once, are split among translators working against the same termbase under one terminologist. Deduplication helps here too: real BOMs repeat heavily, and repeated lines are translated once. Standing clients with termbases in place see most of a new BOM pre-translate from memory, which shortens timelines further.
What does a BOM translation error actually cost?
The error itself is cheap; its propagation is not. A single wrong part name flows into picking systems, spare parts catalogs, service documentation, and customs descriptions, and each copy has its own correction cycle. Real consequences we have seen at client sites include wrong parts picked on an assembly line, a warranty claim disputed over a part name mismatch, and pallets held at the border because the Spanish packing description had drifted from the English invoice. The engineer query round exists precisely to stop these at the source.
Do you translate part numbers, reference designators, or supplier codes?
Never. Part numbers, drawing numbers, reference designators such as R14 or U7, manufacturer part numbers, and supplier codes are locked as do-not-translate tokens in our tooling before work begins, so they cannot be altered even accidentally. The same applies to units, quantities, and revision identifiers. What gets translated is the descriptive text: item descriptions, material names, notes, and long-text fields. The intake step defines this boundary explicitly, and you approve the field classification before any translation starts.