Credit Limit Checks Overview
In this article
What the user sees
When the check runs
What actually gets checked is a setup decision
What counts as exposure
How the check works
Worked example: a standard order release
How the check works across intercompany
Worked example: intercompany
Foreign currency credit limits
When the check quietly does nothing
Troubleshooting
ProduceLinc checks a customer’s credit limit at several points in the order and trade workflow. It uses the standard Business Central credit limit calculation, but treats the result differently: where standard Business Central warns you and lets you continue, ProduceLinc stops the action.
This article explains when the check runs, what it counts, and — for businesses that trade through intercompany partners — how a second check in the partner company works alongside it.
What the user sees
When a check fails, the outcome depends on which limit was breached.
- A limit in the company the order was raised in — the standard Business Central notification appears, “The customer’s credit limit has been exceeded”, with a Show details action. The action then fails to complete. There is no separate pop-up error message.
- A limit in an intercompany partner company — a full error message appears, naming the partner company and the customer whose limit was breached.
In both cases the action is rolled back and nothing is saved. The user cannot continue past the check.
When the check runs
Releasing an outbound produce order
This is the main credit gate in the standard workflow. The check runs only for outbound orders, and only where the order has a value. The pallets on the order are re-priced immediately beforehand, so the check always works with current figures.
Adding pallets to a container
Runs only on outbound trip legs. Transfer and inbound legs are excluded.
Creating or updating a Produce Trade from a container
Runs only for pallets that are not already on a produce trade.
The check also runs in the legacy allocation method, for businesses still using it:
Closing the Pallet Allocation Summary page
Runs once for every line in the allocation batch that has a value. It is skipped entirely if every line in the batch is a freight allocation.
Release from Batch on the Pallet Allocation page
Runs only for sales allocation lines that have an intended sales price.
What actually gets checked is a setup decision
There is no ProduceLinc setting that switches credit checking on or off. The control is Credit Warnings in Sales & Receivables Setup, and it decides which of the two possible checks are performed.
- Both Warnings — the credit limit and the overdue balance are both checked. Either one can block the action.
- Credit Limit — only the credit limit is checked. An overdue balance is never looked at and will not block anything.
- Overdue Balance — only the overdue balance is checked. The credit limit is never looked at, however far it is exceeded.
- No Warning — nothing is checked. The credit check exits immediately at every point above, and no transaction is ever blocked.
Where the setting is anything other than No Warning, the check runs at every point above, every time.
Note
Every company has its own Credit Warnings setting, and it always governs credit checking in that company.
This becomes important where intercompany partners are used. A second check then runs in the partner company, and that check reads the partner company’s setting — not the setting in the company where the order was raised. The two companies can be configured differently, and each governs its own check. See How the check works across intercompany below.
What counts as exposure
The figure ProduceLinc tests is the total outstanding value of the customer’s pallets. For each pallet:
- Intended sales price × the quantity multiplier
- less whatever has already been posted to a Produce Trade
- converted to local currency
- never less than zero
Deducting the posted amount is what prevents double-counting. As value posts through to a produce trade, it drops off the pallet side — but it does not leave the calculation, because it reappears in the customer’s balance. This is shown in the worked example below.
Pallets only count once their order is released
This is the single most important rule to understand.
A pallet allocated to an outbound produce order that is still Open or Submitted counts as zero. It contributes nothing to the customer’s exposure, however large the order is or however many pallets are on it.
Those pallets start counting the moment the order is Released — and releasing the order is itself the moment the check runs. The release is therefore both the trigger and the cause: the order being released is included in the figure that decides whether it may be released.
A customer’s credit exposure is, in practice, the value of their released order book.
Note
Where the legacy allocation method is used, pallets allocated without a produce order count immediately, as soon as they carry an intended sales price. There is no equivalent staging period.
Closing a produce trade clears what is left on its pallets
Where the produce is sold for less than the intended sales price, the difference stays on the pallets as outstanding exposure until the trade is dealt with.
When a produce trade is set to Closed, ProduceLinc treats the income on those pallets as final and sets their outstanding amount to zero. The un-invoiced difference is removed from the customer’s exposure, because the system now knows it will never be billed.
If the amount posted is less than the intended amount, you are warned before this happens:
The total amount posted for this produce trade is (posted) which is less than the total intended amount of (intended). Do you wish to close (trade no.)?
That message is telling you exactly how much exposure is about to drop away. Reopening the trade restores it.
How the check works
- ProduceLinc finds the customer’s bill-to customer. A blank Bill-to Customer No. means the customer bills itself.
- It adds up the outstanding pallet value for every customer that bills to that same bill-to customer, plus the bill-to customer’s own pallets.
- If the bill-to customer is linked to an intercompany partner, the intercompany check runs first. If that passes, the check below still runs. Both have to pass.
- That whole group total is handed to Business Central as though it were a new, unposted invoice for the bill-to customer.
Business Central compares against the bill-to customer’s Credit Limit (LCY), adding up:
- the customer’s outstanding balance
- goods shipped but not yet invoiced
- outstanding sales orders and invoices
- less returns and prepayments
- plus the entire pallet exposure figure
Two consequences are worth understanding before looking at the examples.
The test is on the whole bill-to group’s exposure, not just the order being released. It is a total-exposure test, not an incremental one, and every check adds the full book again.
A credit limit of zero means no limit, not a limit of nothing. A customer with Credit Limit (LCY) left at zero will never block anything.
Worked example: a standard order release
This is the ordinary case. The customer is not linked to an intercompany partner, so only one check runs. All amounts are in the company’s local currency, shown here as ZAR.
Customers
HeadOffice01— the bill-to customer. It bills itself and has no intercompany link. Credit Limit (LCY) R 6,000,000, Balance (LCY) R 1,250,000.Retail01— a sell-to customer, with Bill-to Customer No. set toHeadOffice01Retail02— a sell-to customer, also billing toHeadOffice01
Current exposure — pallets on released outbound produce orders
Retail01— R 2,600,000Retail02— R 1,900,000HeadOffice01— R 150,000
Scenario 1: releasing a small order for Retail02
A new outbound produce order for Retail02, worth R 300,000, is ready to release. Until now its pallets have counted as zero.
At release, the bill-to resolves to HeadOffice01 and the whole customer group is totalled, with the new order now included:
| Customer | Released pallet value |
|---|---|
| Retail01 | R 2,600,000 |
| Retail02 (R 1,900,000 already released + R 300,000 on this order) | R 2,200,000 |
| HeadOffice01 | R 150,000 |
| Group total | R 4,950,000 |
That group total is tested against HeadOffice01:
| Credit calculation | Amount |
|---|---|
| Pallet group total | R 4,950,000 |
| plus HeadOffice01’s balance | R 1,250,000 |
| Credit amount | R 6,200,000 |
| HeadOffice01 Credit Limit (LCY) | R 6,000,000 |
| Blocked, over by | R 200,000 |
The user sees the credit limit notification and the order stays unreleased.
Note what caused this. The user was releasing a R 300,000 order for Retail02, but the block comes from the combined released book of the whole group — including Retail01, which the user never touched — together with HeadOffice01’s own balance. A R 300,000 order was refused against R 4,650,000 of exposure that already existed.
Scenario 2: invoicing on its own does not create headroom
A common assumption is that invoicing some of the outstanding produce will free up credit. On its own, it does not.
R 400,000 of Retail01’s produce is invoiced through a produce trade. Two things happen at once:
Retail01’s pallet exposure falls by R 400,000, because the posted amount is deductedHeadOffice01’s Balance (LCY) rises by R 400,000, because there is now an open invoice on the account
The same order is tried again:
| Credit calculation | Amount |
|---|---|
| Retail01 (R 2,600,000 less R 400,000 now invoiced) | R 2,200,000 |
| Retail02 | R 2,200,000 |
| HeadOffice01 | R 150,000 |
| Group total | R 4,550,000 |
| plus HeadOffice01’s balance (R 1,250,000 + R 400,000 invoiced) | R 1,650,000 |
| Credit amount | R 6,200,000 |
| HeadOffice01 Credit Limit (LCY) | R 6,000,000 |
| Blocked, over by | R 200,000 |
The credit amount has not moved by a single rand. The exposure simply changed form — from produce that will be invoiced, into an invoice that has not been paid. The credit limit measures both.
Scenario 3: closing the produce trade releases the difference
Retail01’s produce trade covered pallets with an intended value of R 700,000, of which only R 400,000 was invoiced. The fruit sold for less than expected, so R 300,000 will never be billed — but it is still sitting on the pallets as exposure.
The trade is set to Closed. Because the posted amount is less than the intended amount, the confirmation appears, naming both figures. On confirming, the R 300,000 is cleared from those pallets.
| Credit calculation | Amount |
|---|---|
| Retail01 (R 2,200,000 less the R 300,000 cleared on closing) | R 1,900,000 |
| Retail02 | R 2,200,000 |
| HeadOffice01 | R 150,000 |
| Group total | R 4,250,000 |
| plus HeadOffice01’s balance | R 1,650,000 |
| Credit amount | R 5,900,000 |
| HeadOffice01 Credit Limit (LCY) | R 6,000,000 |
| Passes, with headroom of | R 100,000 |
The order releases.
Nothing was paid and nothing further was invoiced. The headroom appeared because the system stopped counting income that is never going to arrive.
Note
There are only two ways a customer’s credit exposure genuinely reduces: closing produce trades, which clears intended income that will not be billed, and payment, which reduces the balance with nothing added back. Invoicing, posting and shipping all move value from one part of the calculation to another without reducing the total.
Where credit is tight, unclosed produce trades are the first thing to review — particularly account sale trades that realised less than the intended price.
Scenario 4: exposure that is not yet visible
Retail01 has a further R 1,200,000 of outbound produce orders sitting at Submitted, fully allocated but not yet released. Those pallets currently count as zero, so nothing about them appears in any credit figure.
If they were released today:
| Credit calculation | Amount |
|---|---|
| Current group total | R 4,250,000 |
| plus the Submitted orders once released | R 1,200,000 |
| Group total | R 5,450,000 |
| plus HeadOffice01’s balance | R 1,650,000 |
| Credit amount | R 7,100,000 |
| HeadOffice01 Credit Limit (LCY) | R 6,000,000 |
| Would be blocked, over by | R 1,100,000 |
The customer is already committed well beyond their limit, and no credit figure anywhere reflects it. The problem only surfaces when someone tries to release those orders — most likely close to a loading deadline.
Note
This is the most common source of confusion around credit limits. Orders are captured and confirmed without difficulty for days or weeks, and the credit problem appears only at release, for value that was committed much earlier.
How the check works across intercompany
This section applies only where a business trades through intercompany partner companies and the bill-to customer is linked to an intercompany partner. Where that is not set up, only the check described above runs.
Where it is set up, an additional check runs first, in the partner company. It is measured against a different customer, in a different company, in a different currency, and over a different set of pallets.
Following the link
The distinction to remember: the bill-to customer decides whether the intercompany check runs; the sell-to customer is the key that finds the customer in the partner company.
- The intercompany partner named on the bill-to customer is read in the source company. Its Inbox Type must be Database, and its Inbox Details name the partner company.
- In the partner company, ProduceLinc looks for an Intercompany Partner whose Code is the sell-to customer number from the source company. That record points at the customer to check in the partner company.
- A missing or blank customer in the partner company raises an error.
- If that partner customer is itself linked onward to another intercompany partner, the check hops again into a third company.
Unless there is a further hop, the limit tested is that partner-company customer’s own Credit Limit (LCY) — even if it bills to a head-office customer inside the partner company.
Note
The check in the source company rolls exposure up to a bill-to customer. The intercompany check does not — it only ever looks at the single order’s sell-to customer and that customer’s own pallets.
The currency conversion
The source company’s local currency is looked up as a currency in the partner company, and the latest exchange rate on or before the work date is used to convert the amount into the partner company’s local currency. That exchange rate should be set up with an Exchange Rate Amount of 1.
The customer’s own Currency Code plays no part in this. Both Balance (LCY) and Credit Limit (LCY) are held in the partner company’s local currency, so that is what the comparison uses.
Overdue balances
If the partner company’s Credit Warnings setting includes the overdue balance — that is, Both Warnings or Overdue Balance — then an overdue balance in the partner company blocks just as effectively as a breached credit limit, with no credit limit involved at all. Where the setting is Credit Limit only, an overdue balance is never looked at.
Worked example: intercompany
A source company sells through a partner company. The source company’s local currency is ZAR; the partner company’s is EUR.
Source Company
BillEurope— the bill-to customer. It bills itself and carries the intercompany link to the Partner Company. Credit Limit (LCY) R 8,000,000, Balance (LCY) R 2,100,000.Cust01Europe— a sell-to customer, billing toBillEuropeCust02Europe— a sell-to customer, billing toBillEurope
Partner Company
- Intercompany Partner
Cust01Europe→ customerCust01in the Partner Company - Intercompany Partner
Cust02Europe→ customerCust02in the Partner Company Cust01— Currency Code USD, Credit Limit (LCY) € 270,000, Balance (LCY) € 80,000Cust02— Currency Code EUR, Credit Limit (LCY) € 190,000, Balance (LCY) € 45,000- ZAR exchange rate in the Partner Company: 0.0500
Current exposure in the Source Company — pallets on released outbound produce orders
Cust01Europe— R 3,000,000Cust02Europe— R 2,400,000BillEurope— R 0
Each scenario below starts from this same position.
Scenario 1: releasing an order that passes both checks
An outbound produce order for Cust02Europe, worth R 200,000, is released. Cust02Europe’s exposure becomes R 2,600,000 (R 2,400,000 already released + R 200,000 on this order).
The intercompany check, in the Partner Company against Cust02:
| Credit calculation | Amount |
|---|---|
| R 2,600,000 × 0.0500 | € 130,000 |
| plus Cust02’s balance | € 45,000 |
| Credit amount | € 175,000 |
| Cust02 Credit Limit (LCY) | € 190,000 |
| Passes, with headroom of | € 15,000 |
Then the check in the Source Company, against BillEurope:
| Credit calculation | Amount |
|---|---|
| Pallet group total (R 3,000,000 Cust01Europe + R 2,600,000 Cust02Europe) | R 5,600,000 |
| plus BillEurope’s balance | R 2,100,000 |
| Credit amount | R 7,700,000 |
| BillEurope Credit Limit (LCY) | R 8,000,000 |
| Passes, with headroom of | R 300,000 |
The order releases.
Note that Cust01 trades in USD, and USD appears nowhere in any of this. The conversion is ZAR to EUR, driven by the two companies’ local currencies. A customer’s own currency never drives this conversion.
Note
Exposure on
Cust01Europeis only ever tested againstCust01, and exposure onCust02Europeonly againstCust02. Neither can consume the other’s headroom, even though both share the same bill-to customer in the source company.
Scenario 2: the intercompany check blocks
An outbound produce order for Cust01Europe, worth R 1,000,000, is released. Cust01Europe’s exposure would become R 4,000,000 (R 3,000,000 already released + R 1,000,000 on this order).
| Credit calculation | Amount |
|---|---|
| R 4,000,000 × 0.0500 | € 200,000 |
| plus Cust01’s balance | € 80,000 |
| Credit amount | € 280,000 |
| Cust01 Credit Limit (LCY) | € 270,000 |
| Blocked, over by | € 10,000 |
The user gets the full error message naming the Partner Company and Cust01. The check in the Source Company never runs, because the intercompany failure stops everything at that point.
Nothing visible in the Source Company explains this block — the answer is on Cust01 in the Partner Company, and the error message is what points you there.
Scenario 3: the intercompany check passes but the local one blocks
Both checks must pass. Passing the intercompany check does not end the process.
A smaller order for Cust01Europe, worth R 600,000, is released instead. Cust01Europe’s exposure becomes R 3,600,000 (R 3,000,000 already released + R 600,000 on this order).
Intercompany check on Cust01:
| Credit calculation | Amount |
|---|---|
| R 3,600,000 × 0.0500 | € 180,000 |
| plus Cust01’s balance | € 80,000 |
| Credit amount | € 260,000 |
| Cust01 Credit Limit (LCY) | € 270,000 |
| Passes, with headroom of | € 10,000 |
Check in the Source Company against BillEurope:
| Credit calculation | Amount |
|---|---|
| Pallet group total (R 3,600,000 Cust01Europe + R 2,400,000 Cust02Europe) | R 6,000,000 |
| plus BillEurope’s balance | R 2,100,000 |
| Credit amount | R 8,100,000 |
| BillEurope Credit Limit (LCY) | R 8,000,000 |
| Blocked, over by | R 100,000 |
The symptom here is different. There is no intercompany error message — the user sees only the standard credit limit notification, and the cause is entirely within the Source Company.
Note
Where a bill-to customer should never constrain intercompany trading, leave its Credit Limit (LCY) at zero. A zero limit means no limit, so only the partner companies’ limits will apply.
Foreign currency credit limits
ProduceLinc only ever reads Credit Limit (LCY). Where a business maintains credit limits in a customer’s trading currency and converts them into the local currency — whether manually or by a scheduled job — the credit check uses the converted value only.
If that conversion has not been run since the limit was changed, the check will keep using the old figure. Whenever a limit has been increased but orders are still blocked, check when the conversion last ran.
A customer trading in the company’s own local currency is not affected, because its foreign and local currency limits are always the same figure.
When the check quietly does nothing
Each of the following produces the same outcome as a successful check — the order releases. None of them is recorded anywhere.
The user switched off the notification
Business Central only flags the breach if the credit limit notification is enabled for that user under My Notifications. Switch off “The customer’s credit limit has been exceeded” and nothing fires, for that user only. Another user releasing the same order is still blocked.
This is the only cause that makes the same action behave differently for different people, so it is worth checking first whenever credit blocking appears inconsistent.
Credit Warnings excludes the check being relied on
No Warning disables both checks. Credit Limit silently switches off the overdue balance check, and Overdue Balance silently switches off the credit limit check. In each case the omitted check simply never happens, and nothing indicates that it was skipped.
Credit Limit (LCY) is zero
Zero means no limit. Nothing will ever block for that customer.
The intercompany link does not resolve
Where intercompany is in use, two setup faults cause the intercompany check to be skipped without any message:
- The intercompany partner’s Inbox Type is not Database
- The partner company has no Intercompany Partner record whose Code matches the sell-to customer number
In both cases the order releases as though the partner limit did not exist.
Troubleshooting
Nothing happens when I release an order
The credit limit in the company the order was raised in. Check the bill-to customer’s Credit Limit (LCY) against the whole group’s exposure, not just the customer on the order.
It blocks for one user but not another
The credit limit notification is switched off for that user under My Notifications.
A small order is blocked
The check tests the customer group’s entire released book, not just the order being released.
We invoiced a large amount but it still blocks
Invoicing moves value from produce exposure into the customer’s balance. Both are counted, so the credit amount does not change.
We need headroom and cannot wait for payment
Review the customer’s open produce trades. Where the produce realised less than the intended sales price, closing the trade clears the difference from their exposure.
Exposure jumped with no new orders
An outbound produce order was released, bringing its pallets into the calculation for the first time. A produce trade being reopened will do the same.
Orders were fine all week and now nothing releases
Exposure that accumulated at Submitted has begun to be released. Review the customer’s unreleased order pipeline, not only what is already released.
The intercompany check never seems to run
The intercompany partner’s Inbox Type is not Database, or the partner company has no Intercompany Partner record matching the sell-to customer number. Neither fault is reported.
Every intercompany order suddenly blocks
Check the exchange rate set up in the partner company for the source company’s local currency. It should have an Exchange Rate Amount of 1.
Blocked, but the limit is not exceeded
An overdue balance, which blocks whenever Credit Warnings is set to Both Warnings or Overdue Balance.
A limit was raised but it still blocks
Where limits are maintained in a foreign currency, the conversion into Credit Limit (LCY) has not been run since the change.
Nothing ever blocks
Credit Limit (LCY) is zero, or Credit Warnings is set to No Warning or Overdue Balance so the credit limit itself is never checked.