A Limit of Authority in SAP is a maximum dollar value that a nominated role can authorise to either spend in purchasing, or stock adjust in inventory management.
The system works in almost exactly the same way a military command structure does. I think that's why I found an understanding of Limits of Authority and Need to Know Visibility/Authorisations so easy to operate in comparison to civilian learners on the system.
Military personnel management always makes a clear distinction between the person and the role - the Ships Captain assumes the same responsibilities and authorizations regardless of the name of the individual occupying the Post. Roles always have fairly well understood limits to authority. A sailor knows what decisions she can reasonably make without having to consult the Leading Seaman. The Leader knows her limits of authority before she has to refer the decision to the Petty Officer. The Petty Officer knows when the decision should be run past the Chief Petty Officer or Warrant Officer. The Warrant Officer is fairly clear on the left & right of arc when advising the Midshipman or Lieutenant and so on & so forth all the way up the chain to the Prime Minister. Everyone has a fair idea on what resources they can "spend" independently to achieve a task. Spend limit increases according to the responsibility of the role.
SAP imposes limits of authority as a <= equation against an assigned approval authority - assigned to the role - not the individual.
A quick explanation of the purchasing process provides the simplest example. Lets talk about the purchasing of food for ships. The cook on the STS Young Endeavour (yep its an Australian Navy crewed ship) needs to restock the galley with fresh apples. For the sake of the example we'll say that Cookie has no purchasing authority - that is - the Navy will not honour any bills the cook as an individual incurs in purchasing. Cookie does not have a Navy credit card for procurement and must buy everything using a purchase order.
Cookie would choose one of the pre-approved suppliers of the best quality apples within budget constraints in port and obtain a quote for the required quantity of apples. Cookie would then raise a requisition in SAP which specifies preferred supplier, quantity, item description, quoted price, required delivery time and delivery location. A copy of the quote is attached to the requisition for verification of due purchasing process. SAP assigns a unique identifier number to the requisition and it goes into a queue to be processed by the Buyer who might be sitting in Sydney. When the Requisition passes the required Buyers checks it will be converted into a purchase order and given a Purchase Order Number which is then assigned to the Approving Authority for approval. The Approving Authority might be the Ships Executive Officer (XO). If the total value of the order is under the XO's approval limit (let's say $500 per order) the XO can approve. SAP sends the Purchase order to the supplier - supplier fills the order and invoices the Navy for payment. If the Purchase order totals $500.01 the XO bounces it to the next role with a suitable Limit of Authority- might be the ship's Captain. SAP does not send the order to the supplier until the Approval check box is ticked by the Role with the appropriate authority. Suppliers are not paid until receipt of the delivery is verified and a Goods Receipt entered into SAP against the Purchase Order.
I know victualling for ships of the line is handled differently but we need a simple example.
In short - people can only spend what Navy authorises them to spend - with the suppliers Navy has pre approved. SAP polices the limits on spend and provides total transparency on procurement due diligence. Every transaction is recorded and all users are protected against accusations of fraud by the global built in transparency of the process. Some loss of flexibility in response time is unavoidable - but it is nothing that can not be mitigated by good planning and time management.