Three missing payments and a lost cash discount
Company code 1000 runs the automatic payment programme weekly. On 28 June 2024 AP runs a proposal with next payment date 5 July 2024, payment method T (bank transfer), and gets 37 payments instead of the expected 40. Vendor 100234's invoice 5100000123 (EUR 48,750.00, posted 10 June with payment terms 2/10 net 30) is not in the proposal; the vendor master has payment method T ticked and no payment block. Three other vendors appear in the proposal but are flagged with exceptions in the log. House bank BANK1 has two accounts in bank determination: 1000-1 with an available amount of EUR 250,000 ranked first, and 1000-2 with EUR 100,000 ranked second, but 1000-2 is only assigned to payment method C. The proposal totals EUR 318,000. The controller also notices that all June invoices were paid without the 2% cash discount.
1. Walk through why invoice 5100000123 was not selected at all, distinguishing it from the vendors that were selected but flagged with exceptions.
Read the worked answer
Being absent from the proposal and appearing with an exception are two different failures, and the fix differs.
Absent means the item failed the selection logic:
- Payment block at item level (a document-type or master-level block is not the only possibility - check the item in FB03).
- Payment method in the line item overrides the vendor master; if BSEG-ZLSCH holds a different method, the run does not see it.
- Payment method is not allowed for the country or currency of the paying company code.
- Item amount is outside the minimum/maximum amount for payment method T.
Here the numbers point to the date window: posted 10 June, terms 2/10 net 30 → discount until 20 June, net due date 10 July. The next payment date is 5 July. With no days of grace maintained for method T in company code 1000, an item due 10 July is simply not yet due on 5 July, so it is excluded and will fall into the following run. The exceptions on the other three vendors are different: those items were selected and then failed a check during bank determination or master-data inspection, which is why they appear in the log.
Diagnosis method: filter the proposal log by vendor 100234, then open the item and compare due date, item payment method and item payment block before touching any configuration.
2. The proposal totals EUR 318,000 but only EUR 250,000 of available amount is usable. Explain how bank determination arrived at this, what the exception on the three vendors means, and how to fix it permanently.
Read the worked answer
How bank determination works. For each payment method, currency and paying company code, the system walks the bank ranking order. Each house bank account carries an available amount - a per-run ceiling, not a bank balance. The system fills account 1000-1 first up to EUR 250,000, then moves to the next ranked account. Account 1000-2 carries EUR 100,000 but is only assigned to payment method C, so for method T the ranking list ends after 1000-1. The remaining EUR 68,000 of the proposal has nowhere to go, and the affected items are reported with an exception ('no bank determined' / amount exceeded) rather than dropped silently.
Permanent fix, in order of preference:
- Add account 1000-2 to the bank determination for payment method T with its available amount - cheapest, and it restores the intended two-account design.
- Raise the available amount on 1000-1 if the bank limit genuinely allows it. Do not set an amount you cannot justify against the credit line.
- Use the ranking weights to optimise the number of payments rather than the value, if bank charges per payment are the real driver.
Also verify that the account currency matches, that the house bank ID and account ID are correctly created, and that the payment medium format for method T is assigned - otherwise you fix the amount and hit the next exception in the same run.
3. The controller wants the 2% discount taken on invoice 5100000123. Explain what governs the discount in the payment run and what you would change - and what you would not.
Read the worked answer
What governs it. The payment programme computes the discount itself; nobody enters it. It compares the payment date with the discount days counted from the item's baseline date as defined by its payment terms.
- Baseline date 10 June, terms 2/10 net 30 → discount period ends 20 June, net due 10 July.
- Payment date 5 July → outside the discount period → full amount, no discount deduction.
What to change. Bring the payment date inside the discount window: run the proposal with next payment date 20 June or earlier, limited to the vendors concerned. Accept that the same run will also pick up every other item due by that date - so either run the proposal for a restricted set of vendors, or use a manual individual payment where the volume is small and the run cadence is fixed.
What not to change. Do not alter the vendor master terms or the item to make the arithmetic work - that corrupts the baseline for the next invoice and misstates the ageing.
Check the root cause. If June invoices are being paid without discount systematically, the baseline date at entry is suspect: vendor invoices frequently default to the posting date instead of the invoice receipt date, which starts the discount clock late and makes the discount unreachable in a weekly run. Correct the entry default before changing the run schedule.