A Canadian controller is told her accounts payable process runs at sixty percent touchless and that the benchmark is eighty. The gap becomes a project. What nobody examines is the forty percent, which contains everything the automation could not do and which will contain proportionally more of it after the project succeeds.
Key Takeaway
Sources disagree sharply about achievable straight-through processing rates. A compilation cross-referencing independent benchmarking bodies reports 32.6% of business-to-business invoices processed straight through, with best-in-class at 49.2%. Vendor material describes 80% or more as the 2026 benchmark and 85% plus as the new baseline. We report the conflict rather than resolving it, and note it splits along source type. Separately, practitioner analysis holds that most straight-through processing problems originate at the extraction layer rather than the approval workflow, that template-based document processing creates a hard ceiling in which every new supplier format becomes an exception by default, that confidence threshold misconfiguration sends documents to manual review unnecessarily, and that integration latency creates false validation errors which distort the rate itself. The arithmetic that matters most is that improving a rate from 95% to 99% on a million daily transactions reduces the exception queue from 50,000 to 10,000, so at volume the residual is the operation.
A Conflict Worth Reporting
This article opens with a disagreement in the sources because the disagreement is the most useful thing in the material.
On one side, a compilation that describes cross-referencing public data from several independent benchmarking bodies reports that 32.6% of business-to-business invoices are processed straight through with no human intervention, attributing this to a 2024 dataset, with best-in-class teams reaching 49.2% touchless processing[1].
On the other, vendor material states that the 2026 benchmark is 80% or more touchless[2], and that accounts payable rates of 85% plus are the new baseline expected in 2026, with benchmarks that were 50 to 60 percent and considered good in 2020 now considered laggard[3].
Those are not adjacent estimates. One says a third, the other says four fifths, and both are presented as current.
We are not in a position to resolve it and will not pretend otherwise. What we can do is observe that the split runs along source type, set out what each side is measuring, and give a Canadian finance function a way to think about which number applies to it. That occupies the next three sections.
What Counts As Touchless
The definition, which is stricter than casual use suggests and which matters for reading any of the figures.
Straight-through processing is described as the end-to-end automated execution of a transaction without any manual data entry, review or intervention, measured as a rate, being the percentage of transactions that complete touchless, so that a ninety percent rate means nine of ten transactions flow from intake to completion automatically while the other routes to a human review queue as an exception[3].
The same source draws the operational distinction sharply: a process with twelve automated steps but one mandatory human checkpoint is not straight-through[3].
That is the crucial point for a Canadian firm assessing its own position. The measure is binary per transaction. Automating eleven of twelve steps yields a straight-through rate of zero, not ninety-two percent, and a firm that has substantially automated a process while retaining a mandatory approval has a low rate by this definition and may have achieved most of the available benefit.
An exception is described as occurring when a transaction cannot continue automatically because an issue prevents completion, arising from missing information, incorrect details, failed validations, compliance concerns or mismatched settlement instructions, with such transactions diverted for operational review and correction[4].
Note that the same source qualifies the metric directly: a higher rate generally indicates lower operational friction and fewer exceptions, although high rates alone do not guarantee performance if data quality and operational controls are weak[4].
The Independent Numbers
The lower estimates, and what stands behind them.
The compilation reporting 32.6% describes its method: cross-referencing public data from Ardent Partners, an accounting productivity benchmarking body, an institute of finance management, a treasury association, a payments network body and a federal crime complaint centre, with the stated goal of producing numbers a controller could quote in a budget meeting without an asterisk[1].
It also records the most-used benchmarking metric set as cost per invoice processed, invoice cycle time from receipt to payment, exception rate, touchless processing rate and days payable outstanding[1].
Other non-vendor-aligned figures sit in a similar band. One source reports that most organisations achieve rates between 26% globally for international transactions and 67% for best-in-class implementations, with the rest requiring manual intervention for exceptions, edge cases and scenarios the rules engine cannot handle[5]. Another states that most banks hit a ceiling around 60%[6].
The commonality across these is a reported ceiling well below the vendor baseline, and an attribution of the ceiling to structural rather than tooling causes.
The Vendor Numbers
The higher estimates, reported with their provenance.
One vendor states the 2026 benchmark as 80% or more, and that top performers, naming a large technology company, reached 93% touchless within one week of deploying agentic AI. The same source says most teams are stuck at 30 to 50% touchless, and attributes this to four structural barriers: poor supplier data quality, disconnected purchase order and receipt systems, manual exception workflows, and integration gaps, asserting that AI agents address all four simultaneously[2].
Another reports that organisations replacing template-based document processing with AI-native alternatives report 70 to 90% reductions in manual exception handling, with rates improving from below 60% to above 80% within the first two quarters of deployment[7].
A third reports that vendor case studies show up to 85% no-touch rates are possible[1], which is notable because it appears in the same compilation that reports the 32.6% figure, and is explicitly labelled there as a vendor case study rather than as benchmark data.
We would flag the ninety-three percent in one week claim specifically. It attaches a named company to an extraordinary result on an extraordinary timeline, in vendor marketing, without a citation a reader can check. That does not make it false. It does make it unusable as a planning assumption.
Reading The Gap
How a Canadian finance function should hold the conflict, offered as our own analysis.
Three readings are available and they are not exclusive.
The populations differ. The 32.6% figure is a cross-industry average of all business-to-business invoices, including the long tail of small suppliers with poor data. A vendor figure is typically drawn from implementations, which are firms that invested and had the invoice mix to justify it. Both can be accurate about different populations.
The measurement differs. The strict definition treats one mandatory checkpoint as disqualifying[3]. A vendor measuring at the point of its own product's handoff, rather than through to payment, would report a higher number on the same process.
The interests differ. One compilation exists to give controllers defensible figures; the other exists to describe what a product achieves. Neither purpose is illegitimate and they produce different numbers.
The practical instruction is that a Canadian firm should not adopt an external benchmark as a target at all. The useful comparison is its own rate over time, on its own definition, stated precisely enough to be reproducible. A target imported from a vendor's implementation base is a target set by someone with a different invoice mix and an interest in the answer.
Raising The Rate Concentrates The Difficulty
The argument we consider most important here, and it is our own, developed from the function allocation reasoning earlier in this series.
An automation increment absorbs the easiest remaining cases, because those are the ones it can handle. What remains is therefore not a smaller version of the original population but a different one, enriched for whatever defeated the system.
Consider a firm moving from sixty percent to ninety percent. It has not reduced its exception difficulty by three quarters. It has removed thirty percentage points of the most tractable exceptions and retained a residue that is, by construction, entirely composed of the hard cases.
This is the designer's irony from the function allocation literature, expressed as a rate. The tasks left to humans are the ones the system could not solve, which are the hardest in the process, and the better the automation the more purely that is true.
Two consequences follow that most programmes do not plan for.
Average handling time per exception should be expected to rise as the rate rises, so a business case projecting exception effort as proportional to exception count will overstate the saving.
And the skill required in the exception team should be expected to rise. A team sized and staffed for a mixed population is mis-staffed for a residue of difficult cases, and the article on deskilling in this series argues that the people handling that residue are simultaneously losing exposure to the routine work that built their judgment.
The Arithmetic Of The Residual
The scale point, which one source states cleanly.
Improving the rate from 95% to 99% on a platform processing one million transactions per day reduces the daily exception queue from 50,000 to 10,000 items, which translates directly to staffing cost savings and faster resolution[8].
Read it in the other direction, which is the direction that matters for a control conversation. At ninety-nine percent, ten thousand transactions a day still require a person.
The residual scales with volume, not with the failure rate. A high rate on a large population produces an operation; the same rate on a small one produces a manageable queue. The rate alone tells you nothing about staffing, and it is the rate that gets reported.
For a mid-sized Canadian firm the numbers are smaller and the shape is identical. A ninety percent rate on two thousand invoices a month is two hundred exceptions, which at the difficulty concentration described above is a meaningful and skilled workload.
The useful headline metric is therefore not the percentage but the absolute exception count and the effort it consumes, which is the number that determines what the team does all day and the number almost nobody puts in a board pack.
It Is An Extraction Problem
The diagnostic claim that redirects most improvement effort, and it is the most actionable thing in the practitioner material.
One source states it directly: the gap is not a workflow problem, it is almost always an extraction problem, and most straight-through processing problems originate at the extraction layer rather than the approval workflow[7].
Another makes the same point from the document side: for document-based workflows covering invoices, forms and contracts, automation quality depends heavily on the reliability of upstream data extraction, and when document parsing introduces structural inconsistencies or ambiguous field relationships, downstream validation rules become more complex and exception queues grow[5].
The reason this matters is that improvement effort naturally goes to the visible layer. Exceptions appear in a queue, the queue is a workflow artefact, and so the workflow is where teams look: routing rules, approval thresholds, escalation paths.
If the cause is upstream, that effort improves the handling of exceptions without reducing their number. The queue becomes better organised and remains the same size.
The instruction for a Canadian firm is to categorise a sample of exceptions by cause before designing any workflow improvement. If most trace to fields not read correctly, or read with low confidence, or read from an unfamiliar layout, then the workflow is not the constraint and improving it will not move the rate.
Every New Format Is An Exception
The specific mechanism behind the ceiling, and why it particularly affects smaller firms.
One source states that template-based document processing creates a hard ceiling, because every new vendor format becomes an exception by default, and contrasts this with contextual scoring that handles format variability which binary pass-or-fail logic cannot[7].
The dynamic is worth working through. A template system recognises layouts it has been configured for. A supplier that changes its invoice design, or a new supplier, produces a document the system does not recognise, which becomes an exception until someone builds a template.
The ceiling is therefore a function of supplier churn rather than of document volume. A firm with a stable supplier base and high volume per supplier can reach a high rate. A firm with many suppliers, changing frequently, and low volume each, cannot, because the configuration effort per supplier is never amortised.
That second profile describes a great many Canadian mid-market businesses, and it explains something controllers report as puzzling: that their rate plateaus despite continued investment. The plateau is where new-format arrival matches template-building capacity.
The vendor material's four barriers include poor supplier data quality, with the observation that invoices submitted without purchase order numbers, with incorrect vendor names, or in non-standard formats reduce extraction accuracy and multiply exceptions[2]. That locates a substantial part of the problem outside the firm entirely, in the practices of its suppliers, which is a constraint no internal project addresses.
The Confidence Threshold Problem
A cause named in the practitioner material that connects directly to earlier findings in this series.
One source lists confidence threshold misconfiguration as sending too many documents to manual review unnecessarily[7].
The mechanism is that extraction produces a confidence score per field, a threshold determines what proceeds automatically, and a threshold set conservatively routes correct extractions to humans.
Two observations, and these are our own analysis building on the hallucination measurement article in this series.
Tuning the threshold requires knowing whether confidence predicts correctness in your data. That research found calibration to be unreliable in language model contexts, with self-assessments moving opposite to performance, and we would not assume a document extraction confidence score is well calibrated without checking. The check is straightforward: take a sample of extractions across the confidence range and measure actual accuracy at each level.
And the threshold sits on a genuine trade-off rather than having a correct setting. Lowering it raises the rate and admits more errors into the automatic path; raising it lowers the rate and adds review cost. Where the errors admitted are consequential, the conservative setting is right and the resulting lower rate is not a failure.
A firm being told its rate is below benchmark should therefore establish whether the gap reflects a poorly calibrated threshold, a deliberately conservative one, or an extraction problem, because the three call for entirely different responses.
The Metric Is Contaminated
A finding that undermines the number itself, and which we had not seen stated elsewhere.
The same source lists integration latency creating false validation errors that distort straight-through processing rate reporting[7].
The mechanism is that a validation step checks a value against a record in another system. If that system has not yet been updated, the check fails, and the transaction becomes an exception. Nothing was wrong with the transaction or the extraction; the two systems were out of step.
So a portion of the exception population is a timing artefact, and the reported rate is partly a measure of integration synchronisation rather than of automation quality.
The practical implications are direct. A firm may be able to raise its rate materially by changing when validations run rather than by improving any model, which is a cheaper intervention than most on the table. And a rate compared across periods may move because integration timing changed rather than because anything about the automation did.
The diagnostic is to examine whether exceptions cluster by time of day, day of period, or proximity to a batch process. Clustering of that kind indicates latency rather than content, and those exceptions should be separated out before any conclusion is drawn about extraction quality.
Operational Whitespace
The architectural explanation for the ceiling, and a useful term.
One source attributes the ceiling to architecture, describing the remaining transactions as falling into what it calls the operational whitespace, being the space between systems where handoffs, exceptions and coordination live, and noting that when systems do not share context, automation breaks down[6].
The observation is that automation within a system is comparatively easy and automation across systems is where the difficulty concentrates, because each boundary is a place where context is lost.
For a Canadian mid-market firm the boundaries are recognisable: between the document capture tool and the accounting system, between the accounting system and the banking platform, between the purchasing process and the payables process, and between the operating business and the external supplier.
The instruction that follows is to locate exceptions by boundary rather than only by cause. If most arise at one interface, the improvement is an integration project rather than a model project, and the two are usually owned by different people with different budgets.
This also connects to the earlier point about improvement effort. A team looking at a queue sees exception types; it does not see that most of them are generated at one seam, because the queue does not record where the transaction was when it failed.
When The Queue Becomes Administrative
A risk this series has raised in other forms, applied here as our own analysis.
Vendor material reports that with no intelligent triage, exception queues grew, with teams ending up in a process where 40 to 60 percent of invoices were flagged as exceptions requiring human attention[2].
A queue at that proportion stops functioning as an exception mechanism. An exception is meant to be a signal that something requires judgment. When half the population is flagged, the flag carries no information, and the queue becomes a work list.
The automation bias article in this series described the mechanism by which this degrades: where alerts are usually not genuine, operators learn from experience that they are usually not genuine, and clearing them becomes procedural. The control remains in the framework and stops operating in practice.
The measurement consequence is that queue throughput looks healthy throughout. Items enter, items are cleared, and the statistics show a functioning process. What is not visible is the proportion cleared without genuine assessment.
Our recommendation is to treat a high exception proportion as a control problem rather than only an efficiency problem, and to measure the outcome distribution of exceptions. If a large majority are resolved with no change to the transaction, they were not exceptions, and the threshold or the rules that generated them should change.
A Compliance Claim Worth Challenging
An assertion in the material that a Canadian firm should not rely on, and we flag it deliberately.
One vendor source states that auditors and regulators increasingly accept fully logged straight-through transaction trails as equivalent to, or stronger than, human-reviewed transactions for compliance purposes[3].
The claim is offered without citation, without identifying which auditors or which regulators, and by a party with an interest in the proposition being believed.
We are not in a position to say it is wrong, and there is a coherent argument behind it: a complete, immutable log of automated processing may indeed be better evidence than an unsupported human sign-off, and the segregation of duties article in this series noted that a log entry recording an approval is weak evidence of judgment.
What we would say is that whether a control is sufficient is determined by professional standards and, where applicable, by regulators, not by a vendor's characterisation of a trend. A Canadian firm removing a human control on the strength of this sentence would be relying on an uncited assertion about the position of parties who have not been named.
The appropriate step is to ask your own auditor, in advance, what evidence they expect for the specific control you are proposing to automate, and to obtain the answer before the design is built rather than after.
Capacity, Not Headcount
The honest shape of the return, which one compilation reports with unusual directness.
It records that current data shows AI augmenting accounts payable rather than replacing it, citing a vendor report that 72% of finance teams already use AI in the function, with gains showing up in capacity, at three to six additional hours per analyst per week, rather than headcount cuts. It adds that the strategic roles, being vendor relationship management, payment policy and fraud control, are not automatable with current technology[1].
Three to six hours per analyst per week is a real gain and it is not the gain most business cases describe. It is roughly a tenth of a working week, released as capacity rather than realised as cost reduction.
This aligns with the measurement article in this series, which argued that firms should state what they are buying rather than defaulting to a productivity claim. Capacity that is reinvested in higher-value work is a legitimate return; capacity that is reinvested in more volume is the mechanism by which review controls get defunded.
The point about strategic roles is worth carrying into workforce planning. If vendor management, payment policy and fraud control are the parts that persist, then the function's future shape is fewer transactional hours and the same or more judgment hours, which is a different staffing profile rather than a smaller one.
We note that the underlying figure comes from a vendor report cited within an independent compilation, which is a mixed provenance we cannot resolve further.
Designing For Exceptions
The design principles, drawn from the material and extended.
One source states the objective well: the goal is to make exceptions rare, well-instrumented and fast to resolve, with defined thresholds and rules for what becomes an exception, covering amounts, risk scores and missing fields, and automated routing to the right queue with full context[9].
The phrase with full context carries more weight than it appears to. An exception arriving without the reason it was raised, the confidence scores, the document, the matching records and the rule that failed requires the handler to reconstruct the situation before they can address it. Reconstruction time is frequently larger than resolution time, and it is entirely avoidable.
Four additions of our own follow from the arguments above.
Record where the transaction failed, not only why. The boundary matters for diagnosis, and queues generally omit it.
Record the outcome, not only the resolution. Whether the exception resulted in a change to the transaction is the datum that tells you whether it should have been raised.
Measure handling time by exception type over time. The composition argument predicts this rises as the rate rises, and confirming it locally is what makes the staffing forecast defensible.
Separate latency exceptions before analysing anything. They are a timing artefact and including them distorts every other conclusion.
A Worked Case: From Sixty To Ninety
A Canadian firm processing roughly two thousand supplier invoices monthly at a sixty percent touchless rate. The reconstruction illustrates the reasoning rather than reporting a specific engagement.
The current exception population is eight hundred per month, of mixed difficulty. A programme targets ninety percent, which would reduce it to two hundred, and the business case values the saving at three quarters of the current exception effort.
On the composition argument, that overstates it. The three hundred percentage points of exceptions removed are the tractable ones; the two hundred remaining are the residue that defeated a better system, so average handling time should be expected to rise and the effort saving to be less than proportional.
Before starting, the firm categorises a sample. It finds a portion are new or changed supplier formats, which is the template ceiling and is driven by supplier churn rather than by anything internal[7]. A portion cluster at month end and trace to validations running before the ledger updated, which is latency rather than content[7]. A portion arise at one interface, which is operational whitespace[6]. And a portion were routed by a confidence threshold that has never been validated against actual accuracy.
Three of those four are addressable without touching the extraction model, and two are cheaper than the project as scoped. The latency group in particular may resolve by rescheduling a validation.
The firm also asks its auditor what evidence will be expected for invoices that no longer receive human review, before designing the change rather than after.
What To Do
Do not adopt an external benchmark as a target. Independent compilations and vendor material differ by a factor of more than two, and the split runs along source type.
Report the absolute exception count, not only the rate. The residual scales with volume, and it is the count that determines what the team does.
Categorise exceptions by cause before improving workflow. The practitioner claim is that most originate at extraction rather than in the approval process.
Separate latency exceptions. They are a timing artefact that distorts the rate and every diagnosis built on it, and they may be fixable by rescheduling a validation.
Validate the confidence threshold against actual accuracy. Do not assume the score is calibrated, and recognise that a conservative threshold producing a lower rate may be correct.
Locate exceptions by boundary. If they concentrate at one interface, the fix is an integration project, not a model project.
Expect handling time per exception to rise as the rate rises. Each increment removes the tractable cases and concentrates the difficulty in the residue.
Measure exception outcomes. A large majority resolved with no change means they were not exceptions and the rules should change.
Ask your auditor before removing a human control. Sufficiency of evidence is determined by professional standards, not by a vendor's account of a trend.
Plan for capacity, not headcount. The reported gain is a few hours per analyst per week, and the roles that persist are judgment roles.
The Limits Of This Analysis
Several caveats matter. The sources here are almost entirely commercial: vendors of document processing, payables automation, banking platforms and payment infrastructure, plus one compilation that describes cross-referencing independent benchmarking bodies but which we could not verify against those bodies directly. The central benchmark conflict is reported and not resolved, and readers should treat every rate figure in this article as contested. The 32.6% and 49.2% figures are attributed to a 2024 dataset reported at second hand. The claim that a named company reached 93% touchless within one week appears in vendor marketing without a verifiable citation and we report it only to characterise the vendor position. The capacity figure of three to six hours per analyst per week originates in a vendor report cited within a compilation. The compliance assertion about auditor acceptance is uncited and we have challenged it rather than relied on it. The composition argument, the arithmetic reading, the threshold calibration recommendation, the boundary diagnostic, the queue-becomes-administrative analysis and the worked case are our own analysis rather than findings in the cited material. Figures concerning banking, cross-border payments and fraud surveys are drawn from other jurisdictions. This article does not address document capture technology selection, purchase order matching mechanics, payment fraud controls, or Canadian assurance standards on automated controls. Nothing here is a substitute for professional advice on process or control design.
Frequently Asked Questions
What straight-through rate should we target?
Why does our rate plateau despite investment?
Should we work on the approval workflow?
Does raising the rate reduce exception effort proportionally?
Can a logged automated trail replace human review for audit?
What is the honest return?
References
- Billed. (2026, May 20). Accounts Payable Statistics for 2026, on 32.6% of business-to-business invoices processed straight through with best-in-class at 49.2% attributed to Ardent Partners 2024 data, the stated cross-referencing method across several benchmarking bodies, the standard benchmarking metric set, the vendor case study reference to 85% no-touch rates, and the capacity finding of three to six additional hours per analyst per week with strategic roles described as not automatable. Note: a commercial publication; the underlying benchmarking sources were not accessed directly, and the capacity figure originates in a vendor report. billed.app/hub/statistics/accounts-payable-statistics
- ChatFin. (2026, May 8). Touchless AP: What Straight-Through Processing Actually Means, on the 80% plus 2026 benchmark, the claim that a named technology company reached 93% touchless within one week, the assertion that most teams are stuck at 30 to 50%, the four structural barriers including supplier data quality, and the observation that exception queues grew to 40 to 60 percent of invoices without intelligent triage. Note: vendor marketing; the 93% claim is uncited and unverifiable. chatfin.ai/blog/touchless-ap-straight-through-processing-finance-2026
- Superkind. (2026, May 15). Straight-Through Processing, on the definition as end-to-end execution without manual entry, review or intervention, the rate as percentage completing touchless, the operational distinction that twelve automated steps with one mandatory checkpoint is not straight-through, the claim that 85 percent plus is the new 2026 baseline, and the assertion that auditors and regulators increasingly accept logged trails as equivalent or stronger. Note: vendor material; the compliance assertion is uncited. superkind.ai/ai-lexicon/straight-through-processing
- Intellect Design. (2026, June 3). What Is Straight Through Processing?, on the rate as an operational efficiency measure, the qualification that high rates alone do not guarantee performance where data quality and controls are weak, and the definition of an exception with its typical causes. Note: published by a financial technology vendor. intellectdesign.com/resources/blog/what-is-straight-through-processing-and-how-it-works
- LlamaIndex. What Is Straight Through Processing, glossary entry, on most organisations achieving rates between 26% globally for international transactions and 67% for best-in-class, and on document-based workflow quality depending heavily on upstream extraction reliability with parsing inconsistencies growing exception queues. Note: published by a software vendor. llamaindex.ai/glossary/what-is-straight-through-processing
- Backbase. STP in Banking: Why Banks Hit the 60% Ceiling, on most banks hitting a ceiling around 60%, the attribution of the ceiling to architecture, and the concept of operational whitespace as the space between systems where handoffs, exceptions and coordination live. Note: published by a banking platform vendor. backbase.com/blog/straight-through-processing-banking
- KlearStack. (2026, May 8). STP Rate Document Processing: Causes and Benchmarks, on the claim that the gap is almost always an extraction problem rather than a workflow problem, template-based processing creating a hard ceiling with every new vendor format an exception by default, confidence threshold misconfiguration sending documents to manual review unnecessarily, integration latency creating false validation errors that distort rate reporting, and reported improvements from below 60% to above 80% within two quarters. Note: published by a document processing vendor. klearstack.com/blogs/stp-rate-document-processing
- Acquire. (2026, May 8). Straight-Through Processing: Definition and Benefits, on the arithmetic that improving from 95% to 99% on a million daily transactions reduces the exception queue from 50,000 to 10,000 items, and on the failure points that manual processing introduces. Note: a commercial glossary entry. acquire.fi/glossary/straight-through-processing-stp-definition-and-benefits
- Polygon. (2026, April 17). Straight Through Processing: Definition, Mechanics, on the objective of making exceptions rare, well-instrumented and fast to resolve, defining thresholds and rules for what becomes an exception, and automating routing to the right queue with full context. Note: published by a blockchain infrastructure company advocating a related technology. polygon.technology/learn/payment/why-blockchain-is-the-ultimate-form-of-straight-through-processing-stp
This article discusses process automation benchmarks and is provided for general informational purposes. Its sources are almost entirely commercial publications by vendors of related products, benchmark figures are contested by a factor of more than two and are reported without resolution, and one compliance assertion is uncited and has been challenged rather than relied upon. Nothing here is a substitute for professional advice on process or control design.