[{"data":1,"prerenderedAt":438},["ShallowReactive",2],{"blog-\u002Fblog\u002Ftreasury-exception-management":3,"blog-surround-\u002Fblog\u002Ftreasury-exception-management":415,"blog-related-\u002Fblog\u002Ftreasury-exception-management":425},{"id":4,"title":5,"audience":6,"body":10,"cluster":378,"contentRole":379,"conversionGoal":379,"cornerstone":380,"date":381,"description":382,"draft":380,"extension":383,"factCheckedAt":379,"faq":384,"featured":380,"language":379,"meta":394,"navigation":395,"order":396,"originalAsset":379,"path":397,"pillar":398,"primaryKeyword":399,"publicationOrder":400,"relatedProject":379,"releaseScope":379,"reviewCycle":401,"reviewMethod":402,"reviewStatus":403,"reviewedAt":381,"reviewedBy":404,"searchIntent":405,"seo":406,"sources":379,"stem":407,"tags":408,"type":413,"updated":379,"__hash__":414},"blog\u002Fblog\u002Ftreasury-exception-management.md","Treasury Exception Management: Designing the Operating Queue",[7,8,9],"treasury-operations-manager","group-treasurer","treasury-controller",{"type":11,"value":12,"toc":368},"minimark",[13,25,30,42,49,53,56,178,185,189,192,240,246,250,262,265,284,288,300,303,307,339,342,345],[14,15,16,20,21,24],"p",{},[17,18,19],"strong",{},"A well-run treasury is quiet on the normal path and organised on the exceptions."," When everything goes to plan — statements match, limits hold, rates arrive, interfaces run, approvals clear — good treasury is almost invisible. The actual work, and the actual risk, lives in the exceptions: the item that didn't reconcile, the limit that breached, the rate that's missing, the feed that's late, the approval that's stuck. Most teams handle these as scattered firefighting — a bit in this tool, a bit in that inbox, a lot in someone's head. The teams that stay in control handle them as one thing: a designed ",[17,22,23],{},"operating queue",". This is how to build it.",[26,27,29],"h2",{"id":28},"exceptions-are-the-job-treat-them-like-it","Exceptions are the job — treat them like it",[14,31,32,33,41],{},"The instinct is to see exceptions as interruptions to the \"real\" work. Invert that: ",[17,34,35,36,40],{},"the exceptions ",[37,38,39],"em",{},"are"," the real work."," The straight-through path is automated precisely so people can spend their attention on what fell off it. That reframing changes the design goal — you're not trying to eliminate exceptions (you can't), you're trying to make sure not one of them is invisible, unowned, or overdue.",[14,43,44,45,48],{},"An exception nobody sees is the one that becomes an incident. So the first property of a good system isn't speed — it's that ",[17,46,47],{},"everything surfaces in one place",".",[26,50,52],{"id":51},"the-recurring-exception-types","The recurring exception types",[14,54,55],{},"They come from every corner of treasury, but they share a lifecycle. Naming them is the start of designing the queue:",[57,58,59,78],"table",{},[60,61,62],"thead",{},[63,64,65,69,72,75],"tr",{},[66,67,68],"th",{},"Exception type",[66,70,71],{},"What it is",[66,73,74],{},"Typical owner",[66,76,77],{},"Why it's urgent",[79,80,81,98,114,130,146,162],"tbody",{},[63,82,83,89,92,95],{},[84,85,86],"td",{},[17,87,88],{},"Unmatched transaction",[84,90,91],{},"A statement item with no matching entry",[84,93,94],{},"Cash operations",[84,96,97],{},"Hides a real cash difference",[63,99,100,105,108,111],{},[84,101,102],{},[17,103,104],{},"Limit breach",[84,106,107],{},"Position or counterparty exposure over its limit",[84,109,110],{},"Risk \u002F front office",[84,112,113],{},"A control failure, possibly a real risk",[63,115,116,121,124,127],{},[84,117,118],{},[17,119,120],{},"Missing \u002F stale rate",[84,122,123],{},"A valuation with no current market rate",[84,125,126],{},"Market data owner",[84,128,129],{},"Every dependent number is now suspect",[63,131,132,137,140,143],{},[84,133,134],{},[17,135,136],{},"Interface delay \u002F failure",[84,138,139],{},"A feed that didn't arrive or arrived incomplete",[84,141,142],{},"Systems \u002F integration",[84,144,145],{},"Downstream numbers silently wrong",[63,147,148,153,156,159],{},[84,149,150],{},[17,151,152],{},"Overdue approval",[84,154,155],{},"A payment or deal stuck awaiting release",[84,157,158],{},"Approver \u002F ops",[84,160,161],{},"A payment may miss its cut-off",[63,163,164,169,172,175],{},[84,165,166],{},[17,167,168],{},"Failed payment",[84,170,171],{},"An instruction rejected or returned by the bank",[84,173,174],{},"Payments ops",[84,176,177],{},"Money didn't move; someone expects it",[14,179,180,181,184],{},"Different owners, different urgencies — but the ",[37,182,183],{},"same shape",": detect, classify, route, resolve, escalate if it ages. That shared shape is exactly why they belong in one queue rather than six disconnected ones.",[26,186,188],{"id":187},"the-operating-queue-five-properties","The operating queue: five properties",[14,190,191],{},"A queue that actually controls exceptions has five properties. Miss any one and it degrades into the inbox chaos it was meant to replace.",[193,194,195,206,218,228,234],"ol",{},[196,197,198,201,202,205],"li",{},[17,199,200],{},"Detection."," Every exception type is ",[37,203,204],{},"actively surfaced",", not waited-for. A missing interface has to raise itself — silence must be an alert, because the most dangerous exception is the one that produces no error, just a wrong number.",[196,207,208,211,212,217],{},[17,209,210],{},"Classification."," Each item is typed and prioritised on arrival — severity (how bad) and urgency (how soon), the same two-axis discipline that governs ",[213,214,216],"a",{"href":215},"\u002Fblog\u002Fdefect-triage-and-exit-criteria","defect triage",". A limit breach and a cosmetic mismatch don't get the same lane.",[196,219,220,223,224,227],{},[17,221,222],{},"Ownership."," Every item has ",[37,225,226],{},"one"," named owner. \"The team\" owns nothing; a person owns it, or it drifts.",[196,229,230,233],{},[17,231,232],{},"Resolution target."," Each type has a time it should clear by — a target, not a hope. That target is what makes ageing meaningful.",[196,235,236,239],{},[17,237,238],{},"Escalation."," When an item breaches its target, it escalates automatically on a defined path. Escalation isn't failure; it's the queue doing its job.",[241,242,243],"pull-quote",{},[14,244,245],{},"The measure of an exception process isn't how few exceptions you have — it's how few are invisible, unowned, or past their target. You can't stop exceptions arriving. You can stop them hiding.",[26,247,249],{"id":248},"ageing-and-escalation-the-health-of-the-queue","Ageing and escalation: the health of the queue",[14,251,252,253,256,257,261],{},"The single most useful view of a treasury operation is its ",[17,254,255],{},"exception ageing",": how many items are open, of what type, and how long they've sat. It's the operational equivalent of a ",[213,258,260],{"href":259},"\u002Fblog\u002Ftreasury-kpis-measuring-treasury-performance","KPI dashboard"," — a real-time read on whether the team is on top of the work or slowly drowning.",[14,263,264],{},"Two signals matter most:",[266,267,268,278],"ul",{},[196,269,270,273,274,277],{},[17,271,272],{},"The oldest items."," As with defects, the risk hides in the ",[37,275,276],{},"oldest"," open exceptions — usually the hard ones everyone routes around. A queue full of fresh items being cleared is healthy; a queue with a tail of aged items is a problem wearing a calm face.",[196,279,280,283],{},[17,281,282],{},"The trend."," Is the queue clearing faster than it fills, or slowly growing? A growing queue is a staffing, automation, or upstream-quality problem announcing itself early.",[26,285,287],{"id":286},"where-the-operating-model-comes-in","Where the operating model comes in",[14,289,290,291,295,296,299],{},"Exception management is also an ",[213,292,294],{"href":293},"\u002Fblog\u002Ftreasury-operating-model-centralized-vs-decentralized","operating-model"," question: in a centralised treasury, one queue serves the group; in a hybrid, central and regional teams each own their lanes but against shared standards and a shared view. Either way, the anti-pattern is the same — exceptions siloed by tool or team so no one sees the whole, and the same item bounces between owners because responsibility was never assigned. Decide who owns each exception ",[37,297,298],{},"type",", not just each exception.",[14,301,302],{},"Done well, the queue is also the seed of a dashboard, and eventually a tool: a single, prioritised, owned list with ageing and escalation built in. Many treasuries discover their most valuable internal tool isn't a forecaster or a pricer — it's the thing that makes sure nothing falls through the cracks.",[26,304,306],{"id":305},"what-good-looks-like","What good looks like",[266,308,309,315,321,327,333],{},[196,310,311,314],{},[17,312,313],{},"One queue, every exception type"," — nothing lives only in a private inbox.",[196,316,317,320],{},[17,318,319],{},"Detection is active",", including silence-as-alert for interfaces and feeds.",[196,322,323,326],{},[17,324,325],{},"Every item is typed, prioritised, and owned by a person",", with a resolution target.",[196,328,329,332],{},[17,330,331],{},"Ageing is visible and escalation is automatic"," past target.",[196,334,335,338],{},[17,336,337],{},"Ownership is assigned by exception type",", so items don't bounce.",[14,340,341],{},"Treasury will always generate exceptions — matching won't be perfect, feeds will slip, limits will get tested, approvals will stall. The question is never whether they happen; it's whether they're worked as a designed, owned, measured queue or survived as daily chaos. Build the operating queue and exceptions become routine, controlled and provable. Leave them scattered and you'll keep discovering the important one the same way every time: late, and as an incident.",[343,344],"hr",{},[14,346,347],{},[37,348,349,350,354,355,358,359,362,363,367],{},"Part of the ",[213,351,353],{"href":352},"\u002Ftopics\u002Fcash-and-liquidity-management","Corporate Cash & Liquidity Management guide",". See also ",[213,356,357],{"href":293},"the treasury operating model"," and ",[213,360,361],{"href":259},"treasury KPIs",". The ",[213,364,366],{"href":365},"\u002Fnewsletter","newsletter"," sends one finance-systems pattern, product decision or build lesson every two weeks.",{"title":369,"searchDepth":370,"depth":370,"links":371},"",2,[372,373,374,375,376,377],{"id":28,"depth":370,"text":29},{"id":51,"depth":370,"text":52},{"id":187,"depth":370,"text":188},{"id":248,"depth":370,"text":249},{"id":286,"depth":370,"text":287},{"id":305,"depth":370,"text":306},"operations",null,false,"2026-07-28","Treasury runs on exceptions — unmatched transactions, limit breaches, missing rates, interface delays, overdue approvals. How to design one operating queue that catches, routes and clears them.","md",[385,388,391],{"question":386,"answer":387},"What is treasury exception management?","Treasury exception management is the disciplined handling of everything that doesn't go to plan — the unmatched transaction, the limit breach, the missing market rate, the delayed interface, the overdue approval. In a well-run treasury, the normal processes are automated and quiet; the real work is the exceptions, and the question is whether they're caught, routed to an owner, and cleared on time, or whether they pile up unseen until one becomes an incident. Exception management turns that scattered firefighting into a single, designed operating queue: every exception detected, classified, owned, and resolved against a target.",{"question":389,"answer":390},"Why does treasury need a single exception queue?","Because exceptions arrive from everywhere — payments, reconciliation, risk limits, market data, interfaces, approvals — and if each lives in its own tool or inbox, no one sees the whole picture and things fall between the cracks. A single operating queue gives treasury one place where every exception surfaces, so nothing is invisible, ownership is explicit, ageing is measurable, and escalation is automatic when something sits too long. It's the difference between a team that reacts to whatever shouts loudest and one that works a prioritised, owned list — and can prove, to an auditor or a CFO, that exceptions are controlled rather than merely survived.",{"question":392,"answer":393},"What are common treasury exceptions?","The recurring ones are: unmatched or unreconciled transactions (a statement item with no matching entry), limit breaches (a position or counterparty exposure over its limit), missing or stale market rates (a valuation with no rate to price it), interface delays or failures (a feed that didn't arrive or arrived incomplete), and overdue approvals (a payment or deal stuck awaiting release). Each has a different owner and urgency, but all share the same lifecycle — detect, classify, route, resolve, escalate if overdue — which is exactly why they belong in one designed queue rather than five separate ones.",{},true,5.7,"\u002Fblog\u002Ftreasury-exception-management","cash-and-liquidity-management","treasury exception management",171,"annual","editorial","reviewed","Tan Gravam","informational",{"title":5,"description":382},"blog\u002Ftreasury-exception-management",[409,378,410,411,294,412],"treasury","exception-management","controls","reconciliation","pattern","LTknNJTVjLDLxYQ9UfsiE9dSVrQ_A4wKjAOGCrDBz4E",[416,421],{"title":417,"path":418,"stem":419,"type":420,"language":379,"draft":380,"children":-1},"Treasury Data Quality and Governance","\u002Fblog\u002Ftreasury-data-quality-and-governance","blog\u002Ftreasury-data-quality-and-governance","text",{"title":422,"path":423,"stem":424,"type":413,"language":379,"draft":380,"children":-1},"Treasury Exposure Data Quality","\u002Fblog\u002Ftreasury-exposure-data-quality","blog\u002Ftreasury-exposure-data-quality",[426,430,434],{"path":427,"title":428,"description":429},"\u002Fblog\u002Fcash-positioning-vs-cash-flow-forecasting","Cash Positioning vs Cash Flow Forecasting: What's the Difference?","Cash positioning tells you the cash you have now; forecasting projects what you'll have. Two different jobs — and why confusing them costs treasury teams.",{"path":431,"title":432,"description":433},"\u002Fblog\u002Fdirect-vs-indirect-cash-flow-forecasting","Direct vs Indirect Cash Flow Forecasting for Treasury","Direct forecasting builds cash bottom-up from expected receipts and payments; indirect derives it from projected financials. Which to use, over what horizon.",{"path":435,"title":436,"description":437},"\u002Fblog\u002F13-week-cash-flow-forecast","The 13-Week Cash Flow Forecast: A Practical Guide","A rolling, week-by-week projection of cash in and out over the next quarter, on a direct receipts-and-disbursements basis. Why 13 weeks, and how to build one.",1785267483698]