Straight-through processing means a transaction moves from initiation to settlement entirely by system rules, with people involved only when a rule rejects it.
Straight-through processing is the principle that a transaction should be captured once, in structured form, and then travel through every downstream system without being rekeyed or manually reformatted. The term comes from banking and securities settlement, where the goal was to move a trade from order to settlement without paper instructions in between. Applied to a company's own operations it covers order to cash, procure to pay and payment execution: data enters once and every subsequent step reads it rather than retypes it.
The commercial case rests on what rekeying costs beyond the minutes it consumes. Each point where a human transcribes a value is a point where an error can enter, and every error creates a downstream reconciliation, a correction entry and often a customer or supplier conversation. Rekeying also imposes batching, because people work in sessions while systems work continuously, so the process inherits waiting time that has nothing to do with the work itself. A high straight-through rate changes the shape of the finance team as well: effort moves from processing transactions to defining the rules and investigating what falls out of them.
Business Central supports straight-through processing unevenly, and it is worth knowing where. Strong areas: master data that defaults dimensions and posting groups onto documents, approval workflows, the job queue for unattended background posting, SEPA credit transfer payment file export from the payment journal, bank statement import for reconciliation, and the Peppol e-document channel in both directions. Weaker areas: there is no general rules engine that auto-approves within tolerances, no native exception queue, and no orchestration layer across documents, so anything that crosses a boundary the system does not own, a bank portal, a supplier portal, a spreadsheet used for allocations, breaks the chain and forces a rekey. In practice the limiting factor is almost always master data quality rather than the posting engine.
Example of a fully straight-through payable: a Peppol invoice for CHF 4,850 with 30 day terms arrives on day 0, matches its order and receipt line for line, and posts unattended. On day 30 the payment journal proposes it by due date, exports it into an ISO 20022 pain.001 credit transfer file for the company's Swiss bank, and the imported bank statement clears the entry the following day. Four systems touched the transaction, the amount was entered by the supplier once, and no one in finance typed CHF 4,850 at any point.
The classic trap is a local maximum: automating a step so thoroughly that bad data flows straight through and lands in the ledger, where correcting it costs far more than stopping it would have. Straight-through processing without segregation of duties is a second trap, since a single person who can both define the rule and initiate the payment has effectively removed the control. Teams measure a straight-through rate per process, but it only means something read together with the rework rate: a rising rate with rising corrections is automation moving the problem rather than solving it.
Touchless invoice processing is straight-through processing applied to one document type. The broader term covers any transaction chain, including sales orders, payments and bank clearing, and it is the older phrase because it originated in financial settlement.
Not strictly, but a structured inbound channel is what makes the first step reliable, because nothing has to be interpreted. Without it you depend on reading documents, which introduces a confidence question at the very start of the chain.
Zentriq's AI tools automate many of the manual processes around straight-through processing (stp) in Business Central. Learn about the Zentriq Agent or try Zentriq PunchOut to see how AI simplifies procurement in BC.