Most mid-market companies that delay implementing BoQ automation don't delay because they decided against it. They delay because they're not sure what "ready" looks like, and in the absence of a clear answer, the project stays on the to-do list.
This guide gives you a concrete answer. It covers what you actually need before implementation starts, what you can prepare quickly, what takes more time, and what you do not need at all, including several things vendors sometimes suggest are prerequisites but aren't.
The five areas
There are five areas to work through before a BoQ automation implementation starts. None of these require months of preparation. Some take an afternoon. A few require a conversation with your IT contact or ERP provider. One or two require an internal decision.
Product catalog readiness
Historical BoQ data
ERP or system access
Exception handling rules
Internal process ownership
Area
Product Catalog Readiness
What you need: your product catalog in a format the system can read, not necessarily clean or perfectly structured, but accessible.
BoQ automation works by matching incoming line items against your internal product catalog. The matching quality depends on what catalog data is available. This does not mean the catalog needs to be perfect before implementation starts. It means it needs to exist in a readable form.
Area
Historical BoQ Data
What you need: a sample of real BoQs your team has processed, ideally from the last six to twelve months.
Historical BoQs are used during implementation to test and validate the matching logic against your real order mix before going live. They are not required to train a model: turian's matching is LLM-based and does not require labeled training data. But they are useful for two things: configuring the exception handling rules, and giving both your team and the implementation team confidence that the system handles your actual document mix before it touches live orders.
Area
ERP or System Access
What you need: either API access to your ERP, or an email integration point, and someone at your company who can confirm which is available.
This is the step that most often causes unnecessary anxiety. "We don't have our ERP set up for API access" is a common concern. In most cases, the ERP does have API access: it just hasn't been used before, and nobody has confirmed the specifics.
Area
Exception Handling Rules
What you need: a set of decisions about which situations a human must review, and who reviews them.
Exception handling rules are the instructions that tell the system when to proceed automatically and when to stop and ask a human. You do not need to define every possible exception before implementation: you will discover most of them in the first weeks of live operation. But you need to define the threshold cases before go-live.
If the price the system finds in the ERP differs from a price on the incoming BoQ, at what percentage difference should it flag for human review? A practical starting point: flag any deviation above 3% for standard catalog items, tighter for custom or configured products.
Options: flag and hold the entire order, flag the unmatched lines and continue with matched lines, or route the full document to a named person.
Should items outside your product range be automatically marked as "not applicable" and excluded from the quote, or flagged for a human to confirm exclusion?
Should BoQs from customers not yet in your ERP be processed automatically or held for manual review pending account creation?
If a BoQ has a tender deadline, should the system flag urgency? Who sees that flag?
Area
Internal Process Ownership
What you need: one named person who owns the implementation on your side, and clarity on who handles the exception queue after go-live.
This is the prerequisite that most implementation guides skip. Technical setup is straightforward. Process ownership is where implementations stall.
One named person at your company who is the primary contact during implementation, who has authority to make configuration decisions, and who will sign off on go-live readiness. A Vertriebsleiter or operations manager is the right person.
Who reviews and resolves exceptions after go-live? This should be a specific person or a defined rotation, not "the team." Assign it before the first exception arrives.
Someone who can provide API credentials, confirm field mappings, and test the ERP write connection. One hour of their time during implementation is usually sufficient.
Which order types, which customer groups, what exception review process. Define this before implementation starts.
How will your exception queue owner communicate configuration changes back to the system? Weekly review of exception patterns, a shared log, or a direct line to the implementation team.
The full checklist
Product catalog
Historical BoQ data
ERP or system access
Exception handling rules
Internal process ownership
Defer these
A few things that vendors sometimes present as prerequisites are actually better addressed during or after live operation.
Full catalog cleanup
A pre-implementation catalog audit takes weeks and delays go-live. The matching process surfaces catalog gaps more effectively than a manual audit: implement first, clean as you go.
Complete customer cross-reference table
Unmapped customer codes are surfaced in live operation as exceptions. Build the cross-reference incrementally based on what actually appears rather than trying to anticipate every mapping in advance.
Edge case exception rules
You will not know your real exception patterns until the system has processed a few hundred real BoQs. Configure the five threshold rules above before go-live; add the rest based on what the exception log shows in the first four weeks.
Full ERP field mapping
Start with the core fields: order header, line items, quantities, prices. Additional ERP fields can be mapped in phase two once the core workflow is stable.
Next step
If you have worked through this checklist and have most items confirmed, you are ready to start. If two or three items are unclear, that is a normal starting point: the implementation scoping call exists to work through exactly these questions.
Book an implementation scoping callBy clicking "Accept", you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
