Manage Virtual Credits for Organizations - Article
Summary
Virtual Credits allow eligible learning purchases to use an organization's credit balance instead of requiring a separate regular-currency payment from each participant. Use them when a customer or business unit funds learning under an agreed credit arrangement and local users or Managers should spend within that balance.
This article explains how to:
- Separate organizational balances from activity and Product credit prices.
- Decide who may spend credits.
- Manage and review credit operations.
- Handle shared memberships, expiration, and returned credits deliberately.
What Virtual Credits help you achieve
A provider may agree a learning allocation with a customer, then let the customer's Manager enroll employees against that allocation. Another program may allow eligible employees to choose training themselves. The provider controls the approved balance and the available credit-priced offers; the organization can use the allocation within the configured rules.
The underlying commercial agreement and the credit balance are related but distinct. Adding credits to an organization does not itself collect a card payment, issue an external invoice, or prove that money has been received. Handle those steps through the agreed financial process.
Virtual Credits are an optional capability. They must be enabled and configured before the relevant organization balance and payment controls appear.
Separate balance, price, and payment permission
| Element | What it controls | What it does not do |
|---|---|---|
| Organization credit balance | The amount available for the organization's eligible purchases. | Define the price of an activity or collect real money. |
| Activity or Additional Product credit price | The amount of credits required for that item where supported. | Automatically convert its EUR, USD, or other regular-currency price. |
| Virtual Credits payment method | Whether credits can be used through the relevant purchase flow. | Make every user eligible to spend an organization's balance. |
| Spending eligibility | Whether spending is limited to Managers or available to eligible organization members. | Remove membership, balance, or checkout validation. |
| Credit operations history | The recorded deductions, returns, and relevant balance operations for the organization. | Replace external invoicing or payment-provider records. |
Maintain credit prices independently from regular-currency prices. Coupons and organization percentage discounts do not reduce Virtual Credit prices. See Discount campaigns and Coupons for the complete pricing workflow.
For maintaining item prices, see Price Manager. This article focuses on the organizational balance and its use.
Decide who should spend the balance
Where Virtual Credits are enabled, the relevant Commerce configuration determines whether they are available to Managers or to All Users who meet the organization requirements.
| Spending model | When it is appropriate | Practical consequence |
|---|---|---|
| Managers | A customer coordinator or line management function should approve the use of the allocation. | The Manager enrolls eligible people and selects the appropriate paying organization where required. |
| Eligible organization members | Individuals are trusted to choose eligible training within the organization's arrangement. | Members can use credits through the permitted checkout route, subject to membership and balance validation. |
Agree this policy before allocating a significant balance. A balance intended for managed spending should not become broadly available simply because self-service enrollment is convenient.
If an activity is offered only through a Manager-controlled credit route, a participant may be directed to contact their Manager rather than being able to enroll independently. The exact presentation also depends on regular-currency prices and available payment methods.
Allocate and maintain the organization's balance
Open the organization, then More → Settings → General. When Virtual Credits are enabled and your role permits balance maintenance, use the credit controls to establish or adjust the approved amount. Credit values are whole numbers. Use the separate Credit operations page to review deductions, returns, and other recorded movements.
Before saving a change, confirm whether the control sets the resulting balance or records an adjustment. These are different financial intentions. If 200 credits remain and a further 100 are approved, the intended new balance is 300; entering 100 into a balance-setting field would not represent a top-up of 100.
For each allocation or correction, retain a clear business reference and reason. Use the available credit-operation comment where permitted, and keep the related contract, invoice, or approval in the organization's normal business system.
| Operation | Administrator's responsibility | Evidence to retain |
|---|---|---|
| Initial allocation | Confirm the organization, amount, spending model, and validity policy. | Approved agreement or allocation reference. |
| Additional allocation | Confirm the additional amount and resulting balance before saving. | Approval and the corresponding commercial reference where applicable. |
| Correction | Establish why the current record is wrong and avoid compensating for an unresolved transaction twice. | Reason, decision owner, and relevant purchase or operation reference. |
| Expiration-related review | Confirm the configured validity rules before communicating a deadline or expected remaining balance. | The approved policy and applicable date. |
Changing a balance is an operational action, not merely a cosmetic update. Limit it to the responsible roles and review unusual adjustments.
Parent organizations and suborganizations
Parent organization credits can be available for use by eligible members and Managers in suborganizations. This allows a central customer allocation to support learning across its branches.
Do not describe the displayed parent balance as a separate allocation for every branch. If several branches draw on a shared funding arrangement, their purchases can reduce the balance available to others.
For a customer requiring guaranteed branch budgets, confirm the supported funding design with the responsible administrator and Eurekos support. Do not assume that creating suborganizations automatically divides the parent's credits into independent budgets. Avoid restructuring the organization hierarchy solely to create a funding separation: the same hierarchy also affects membership, management, and access.
Select the correct paying organization
A person or Manager with several organization relationships may need to choose which organization pays. That selection must be compatible with the participants being enrolled.
For example, a Manager who supports Customer A and Customer B should not enroll Customer A's employees while choosing Customer B's balance. The platform validates organization context and can reject incompatible selections.
Bulk enrollment follows the same principle. Split a mixed population into compatible groups when one paying organization cannot validly fund all selected users.
Before completing a credit purchase, check the participants, the paying organization, the total credit amount, and the available balance. A user can have access to a training offer without being eligible to charge every organization they work with.
Review Credit operations
Open the organization's Credit operations page where available. Use it to understand how the balance has been used and to investigate a customer's questions about deductions or returns.
The history provides the organization context for credit movements. The available report can be downloaded for review and reconciliation. Managers can review the credit information available to their organizational scope; comment editing is reserved for permitted administrative roles.
Use comments to explain the business reason for a relevant entry, not to store unnecessary personal data. Where supported, comments also appear in the exported report's purchase details.
Reconcile the credit record with the corresponding enrollment or Transaction when investigating a purchase. A credit history answers a different question from a payment-provider statement: it shows use of the organization's learning allocation, not a card settlement.
Handle expiration and returned credits
Expiration
Expiration behavior depends on the enabled credit configuration. A platform can use a common fixed expiration date that removes the ability to choose a different date per organization.
Confirm the actual configuration and approved policy before communicating validity to customers. Do not assume that credits always expire at year-end or always remain valid indefinitely when an expiration control is not visible.
Explain the expiry policy when the allocation is agreed and review affected balances before the deadline. A credit price on an activity is not evidence that an organization's credits will remain valid until the activity takes place.
Cancellation and account deletion
Cancellation of a signup or activity paid with credits returns the credits to the organization through the applicable credit flow. Verify the corresponding return in Credit operations before making a separate manual adjustment.
Deleting a user does not itself return the credits spent on that user's training. Likewise, removing an organization membership is not a substitute for cancelling participation or resolving its financial record.
If a transaction or cancellation has an unexpected result, investigate the recorded operation before adding compensating credits. Otherwise, a later automatic return can leave the organization credited twice.
Common funding designs
| Requirement | Recommended design | Business outcome |
|---|---|---|
| A partner prepurchases a training allocation | Establish the agreed balance, maintain intentional credit prices, and allow Manager spending. | Local coordinators can enroll staff without a separate payment collection for every person. |
| Employees choose from an approved learning offer | Enable eligible-member spending where appropriate and maintain the intended audience and payment settings. | Employees can use organizational funding within the configured rules. |
| Several branches share a central budget | Allow supported use of the parent allocation and review consumption across branches. | Funding is managed centrally while learning decisions can remain local. |
| One coordinator serves several customers | Require careful paying-organization selection and separate incompatible bulk enrollment groups. | Each customer's allocation funds the intended participants. |
| A time-limited commercial agreement is approaching its end | Review the actual expiry configuration and remaining balance with the responsible customer owner. | Customers receive an accurate explanation of what remains available and until when. |
Verify the setup
| Scenario or check | Expected result or evidence |
|---|---|
| Spending eligibility Test the intended Manager and participant routes. | Only the permitted roles and members can spend credits. |
| Price and available balance Review an eligible activity's credit price and complete an authorized test purchase. | The intended amount is deducted from the correct organization. |
| Shared organization context Test the required multi-organization or bulk-enrollment case. | Incompatible participants are not charged to an unrelated organization. |
| History and return Review the purchase and an approved cancellation test in Credit operations. | The deduction and return can be traced without duplicate manual correction. |
| Validity policy Compare the configured expiration behavior with customer-facing terms. | The communicated validity matches the actual setup. |
Troubleshooting
| What you observe | What to check |
|---|---|
| Virtual Credits controls are missing | Check that the optional capability and relevant payment configuration are enabled and that your role has access. |
| A user sees a price but cannot enroll with credits | Check Manager-only versus eligible-member spending, organization membership, regular-currency alternatives, and payment methods. |
| There is enough balance but checkout fails | Check the selected paying organization, participant memberships, item credit prices, and the current balance at checkout. |
| Bulk enrollment is rejected | Check whether all selected users are compatible with the same paying organization; divide the group if needed. |
| A Coupon does not reduce the credit amount | Coupons and organization percentage discounts do not apply to Virtual Credit prices. |
| The expected return is absent | Confirm that participation or the activity was cancelled through the applicable flow. User deletion or membership removal alone does not return credits. |
| A credit expiry date cannot be changed for one organization | Check whether a common fixed expiration date is configured for all credits. |
| The balance appears too high after cancellation | Check for both an automatic return and a manual correction before making another adjustment. |
FAQ
-
Does allocating Virtual Credits collect a payment from the organization?
No. Adding credits establishes an organizational learning balance; it does not itself collect money or prove that an invoice was paid. Manage the commercial agreement and settlement through the approved external financial process.
-
Are Virtual Credit prices converted automatically from regular-currency prices?
No. Maintain an intentional credit price separately from EUR, USD, or other regular-currency prices where Virtual Credits are supported. Changing an item price does not fund the organization or change its existing balance.
-
Can Coupons or organization percentage discounts reduce a Virtual Credit price?
No. Coupons and organization percentage discounts do not reduce Virtual Credit prices. Check the configured credit price and the selected paying organization’s available balance.
-
Does deleting a user return the Virtual Credits spent on their training?
No. Deleting the account or removing organization membership does not itself return spent credits. Cancellation of the signup or activity uses the applicable credit-return flow. Check Credit operations before making a manual correction to avoid returning credits twice.