Transactions - Article

What a Transaction is

A Transaction is the traceable record of an enrollment or supported purchase process in Eurekos. It connects the person, commercial context, purchased item, amount, currency, payment method, status, and relevant identifiers.

Every enrollment in a Training Activity creates a Transaction, even when:

• The activity price is zero
• A simple free-enrollment flow lets the learner enroll without a full checkout form
• An administrator enrolls the participant
• Several participants are enrolled through a bulk operation
• A discount reduces the payable activity price to zero
• Payment is deferred through Invoice
• The participant pays with Virtual Credits

This gives administrators a complete record of how access was created, rather than recording only revenue-generating purchases.

Transactions can also represent supported purchases outside a single activity signup, including:

• An Additional Product bought separately after enrollment
• A subscription purchase or recurring subscription payment
• Other subscription changes that create their own commercial event

Open the operational overview from Course Administration → Transactions.

Transactions are historical records and cannot be deleted through the user interface.

A Transaction is evidence—not the complete financial system

Eurekos records the enrollment and commercial context. An external payment provider owns card authorization, capture, refusal, settlement, and card data. An external accounting or ERP system may own invoice issuance, payment receipt, credit notes, and financial posting.

Reconcile the relevant systems before making a financial conclusion.

Keep the related records separate

Several records may describe different parts of the same participant journey.

Use the Transaction as the joining point, then verify the record that owns the specific question.

What the Transactions overview is for

The on-screen overview is an operational investigation tool. Use it when you need to:

• Find one participant’s enrollment or purchase
• Follow up on a failed or interrupted checkout
• Explain why a participant is on a waiting list
• Confirm which payment method and currency were used
• Match a Eurekos record with a payment-provider reference
• Verify whether a Coupon or another discount affected the amount
• Review a purchase containing Additional Products
• Resend an enrollment confirmation
• Give Support or Finance the correct internal and external identifiers
• Inspect the status before cancelling, refunding, re-enrolling, or issuing a replacement Coupon

The overview displays:

• ID
• Buyer
• Activity
• Sub total
• Total
• Changed
• Type
• Customer
• Payment
• Status
• Invoice status where that functionality is configured

The overview can be searched, filtered, and restricted by date. The exact available fields can depend on platform configuration, enabled Commerce features, organization scope, and Transaction type.

Use the overview for individual investigation. Use Analytics → Transactions for a controlled export or reconciliation across many records.

Permissions and data scope

Access to Transactions is role- and scope-dependent. Course Administrator, Support, Platform Administrator, and Global Administrator roles normally use Course Administration for transactional follow-up, subject to the permissions and organization layer configured on the platform. Some optional or customer-specific roles deliberately exclude Transactions.

Access to the operational overview and the Analytics report is controlled separately. Access to Analytics → Transactions is configured under Settings → Analytics permissions.

The organization layer can restrict which activities, users, organizations, and records an administrator may see. When two administrators receive different results, compare their permissions and organization scope before treating a record as missing.

For exported reporting:

• Parent-level access can include permitted sub-organizations.
• A sub-organization does not automatically see upward or sideways into other branches.
• Blocked users can remain visible for historical accuracy.
• Transactions connected with deleted activities remain available as historical evidence.
• Transactions for deleted users are excluded from the Transactions Report.
• Organization columns preserve the organization context recorded when the Transaction was created.

Limit access and exports to people who need the commercial and personal information for a defined operational purpose.

Configure the upstream process before relying on Transactions

Transactions reflect configuration made elsewhere. They do not correct incomplete prices, payment methods, tax rules, customer details, or enrollment design.

Assign commercial and Finance owners before offering paid enrollment. Confirm that customer forms collect the required billing information, checkout agreements and documents are approved, and any Virtual Credit funding is ready. The Invoice model must also allow access at the point intended by your financial policy.

Platform Commerce settings

Platform Administrators configure the overall purchasing model under Settings → Commerce, including:

• Enabled currencies
• Payment methods
• Payment-method availability at activity level
• Customer types
• Tax rules
• Seller registration details
• Checkout agreements
• Order-confirmation and Invoice PDF behavior
• Price-display formatting
• Administrative notification behavior

External payment methods also require a working provider integration under Settings → Third party integrations.

Training Activity price and payment methods

The pricing configuration on a Training Activity controls its available regular-currency and Virtual Credit prices. Where payment methods can be managed at activity level, the activity also determines which enabled methods the buyer may choose.

Before publishing a paid activity, test:

• Every intended currency
• Every permitted customer type
• Each enabled payment method
• Tax behavior for the seller, buyer, location, and online or onsite context
• Organization and Coupon discounts
• Included and Optional Additional Products
• Order confirmation and invoice output
• Successful and unsuccessful payment-provider outcomes

Administrative enrollment

An administrator can specify a price during supported manual enrollment flows when the activity has a price configured. Depending on the available configuration, the administrator may select:

• A regular currency configured for the activity
• Virtual Credits
• Free

The price is initially populated from the activity and can be adjusted in the supported form. If a price is not specified, the regular price and currency can be determined from the activity configuration and the user’s profile context.

Use administrative overrides only under a documented policy. The resulting Transaction preserves what was applied to that signup and should be explainable to Finance, the activity owner, and the participant.

How Transactions are created

The same Transactions overview can contain records created through different routes.

In the current Transactions Report, the Type filter distinguishes:

• Product
• Sign-up
• Personal subscription
• Team subscription
• Managed subscription

Search and filter Transactions

The Transactions overview combines date restrictions, identifier search and operational filters so you can narrow the records before opening an individual Transaction.

1. Open Course Administration → Transactions.
2. Choose a date range that includes when the checkout or enrollment was initiated—not only the activity delivery date.
3. Search by Transaction ID, Hashed/Invoice ID, or buyer email.
4. Use the Activity or Course filter when you know the training rather than the Transaction identifier.
5. Apply the relevant Type, Customer, Payment method, or Status filters.
6. Open the individual Transaction to inspect its details.
7. Compare it with the activity signup and, for online payments, the payment-provider record.
8. Record the identifiers used when handing the case to Finance, Support, or the payment provider.

Do not rely on buyer names or activity titles as general search keys in the Transactions overview.

The available filters include:

• Type
• Customer
• Payment method
• Status
• Activity
• Course

Choose the correct date

The Transaction creation date answers when the commercial or enrollment process was created. It is not necessarily:

• The activity start date
• The date the learner began the course
• The invoice payment date
• The card settlement date
• The date of a later cancellation or refund
• The next subscription billing date

Expand the date range when a known enrollment does not appear. A participant may buy a scheduled activity weeks or months before it starts.

Search and reconcile with stable identifiers

Names, email addresses, and activity titles can change. The search field accepts buyer email, but stable identifiers are preferable for investigation and external reconciliation:

• Transaction ID
• Hashed/Invoice ID or order reference
• Payment-provider Reference ID
• User ID or external user ID
• Activity ID
• Subscription reference where relevant

Not every identifier is a searchable field in the operational overview. Use the Transaction ID or Hashed/Invoice ID to locate the platform record, then use the remaining identifiers to compare related systems and reports.

Understand the Transaction identifiers

Transaction ID

The Transaction ID is the unique internal Eurekos identifier. It is a running number and is the best starting point when Support or another administrator must locate the same platform record.

Do not confuse it with the participant ID, activity ID, payment-provider ID, invoice number, or order reference.

Hashed/Invoice ID

The Hashed/Invoice ID is the reference used on invoice or order-confirmation material. Its documented format contains two groups of five uppercase letters or numbers, for example:

A765F-KE4G3

Use this identifier when the participant sends an invoice, confirmation, or order reference and you need to locate the related Transaction.

Payment-provider Reference ID

An online payment can include a Reference ID generated by the external payment provider. Its structure depends on that provider.

Use it to match the Eurekos Transaction with the provider’s dashboard or support process. A Transaction without an online payment will normally not have this provider reference.

No card data is stored in Eurekos

The platform does not expose card numbers or other credit-card details in Transactions. Use the payment-provider system and its Reference ID for payment authorization, capture, refund, settlement, and dispute investigation.

Read the Transaction details

The live Transaction page is organized into Summary, Order, and Logs.

Summary

The Summary can show:

• Transaction ID
• Type
• Payment method
• Hashed/Invoice ID
• Customer type
• User or buyer
• Training Activity
• Total
• Status
• Created date and time
• Changed date and time

Additional customer, billing, provider, or invoice information can be available depending on the Transaction type and platform configuration.

Order

The Order table shows:

• Product
• Quantity
• Sub-total
• Discount
• Total

Logs

The Logs table records status events with:

• Date
• Status
• Data

Additional report information

The Transactions Report can expose additional information that is not necessarily displayed directly on every Transaction page, including:

• Email, user ID, and external ID
• Country and billing address
• Company information
• Company registration or VAT number
• Purchase-order or EAN reference
• Additional Product and subscription information
• Activity schedule and signup expiration
• List price, discount, net price, tax, total, and currency
• Invoice PDF and invoice status where configured
• External payment-provider Reference ID where applicable

The exact fields shown on screen and available in the report vary by Transaction type, platform features, and report template.

Understand Transaction statuses

Transaction status describes the state of the enrollment or payment process. It does not describe course progress.

A Transaction can also become Completed when a signup changes from Waiting list or Reserved to Registered.

Not every Transaction uses every status

A free or manually administered enrollment does not pass through card authorization and capture. Payment-gateway stages depend on the provider. A waiting-list record follows capacity logic rather than a normal successful-payment sequence.

Do not design monitoring around one assumed linear chain for every payment method.

Pending does not mean “awaiting payment”

In Course Administration Transactions, Pending is assigned when no seat is available and the user is added to the waiting list.

If Finance is waiting for an invoice to be paid, track that receivable in the system that owns invoice settlement. Do not use the Transaction’s Pending status as an accounts-receivable state.

Refused and Authorize refused are different

• Refused concerns a signup cancelled by an administrator.
• Authorize refused concerns payment authorization refused by an external provider.
• Capture refused concerns a later failure to capture an authorized payment.

Choose the matching investigation. Participant administration will not explain a provider decline, and the provider dashboard will not explain why an administrator cancelled a signup.

Completed has important limits

Completed means the Transaction workflow succeeded and the signup was created or promoted to Registered. It does not mean:

• The participant completed the Training Activity
• An invoice managed outside Eurekos was paid
• An online payment can no longer be refunded or disputed
• The participant’s signup was never later cancelled, expired, or moved

Open the record that owns the later event.

Compare Transaction and signup status

The activity participant list uses signup statuses such as:

• Registered
• Reserved
• Waiting list
• Expired
• Cancelled

These describe access or participation. Transaction status describes how the enrollment or purchase process progressed.

Examples:

• A Transaction can be Completed while the participant is now Expired because access ended later.
• A Transaction can be Completed while the participant is now Cancelled because they withdrew after enrollment.
• A Transaction can be Pending while the signup is on the Waiting list.
• A Transaction can change to Completed when the participant moves from Waiting list or Reserved to Registered.
• A captured payment can require investigation if the final signup was not created.

For disputes or audits, preserve both perspectives rather than overwriting one with the other.

Free enrollments

A free Training Activity still creates a Transaction. The record provides evidence of when and how access was granted even though no money changed hands.

If Simple Enrollment Flow for Free Courses is enabled, a registered user may be enrolled immediately without completing the full checkout form. This removes unnecessary billing fields from the learner experience; it does not remove the underlying Transaction.

Free Transactions are useful for:

• Measuring adoption
• Reconciling manual and automatic enrollment routes
• Demonstrating a complete training-access history
• Connecting enrollments with Market Value
• Investigating unexpected access
• Distinguishing free access from missing revenue data

Platform Commerce settings can suppress certain administrative notifications for free enrollments. A missing notification therefore does not prove that no Transaction exists.

Market Value and a free Transaction answer different questions

A zero-value Transaction records how access was granted. Market Value records an administrator-defined estimate of the value delivered. It is not copied into the Transaction as revenue and does not change the Transaction amount.

Use Analytics → Transactions to analyze commercial and enrollment events. Use Analytics → Market value to analyze estimated value.

Do not add the two measures together or treat Market Value as money received.

Online payment gateways

Eurekos can pass payment processing to configured external providers. The available providers and payment methods depend on the platform configuration.

When an online payment fails:

1. Find the Eurekos Transaction.
2. Record its ID, amount, currency, status, creation time, and provider Reference ID.
3. Verify whether a signup exists and its current status.
4. Open the matching provider record.
5. Compare authorization and capture events.
6. Check the provider’s stated failure reason.
7. Confirm the provider integration and activity currency and payment configuration.
8. Avoid creating another paid enrollment until you know whether money was captured.

Invoice Transactions

Invoice allows a participant to enroll without immediate online payment. Eurekos records the Transaction and can produce configured invoice or confirmation material, while the organization handles collection through its financial process.

In the standard invoice flow:

• The signup can be created immediately.
• The participant can receive access immediately, subject to the activity’s schedule and access restrictions.
• No card authorization or capture occurs.
• Eurekos does not automatically make the external invoice paid.
• An external ERP integration or manual export can support invoicing and reconciliation.

This model is generally suited to trusted B2B, partner, or public-sector relationships. If non-payment should prevent access, the organization’s enrollment and financial design must address that requirement deliberately.

Invoice is a payment method, not a settlement status

Do not treat Completed as “invoice paid.” The Course Administration Transaction confirms the enrollment flow. The accounting system must answer whether the receivable was issued, paid, credited, or overdue.

Reconcile Invoice Transactions

Use Analytics → Transactions and filter by the relevant period, customer type, payment method, and status. Export the required billing and commercial fields, then:

1. Match each Transaction ID or Hashed/Invoice ID to the ERP record.
2. Validate buyer, company, PO or EAN, seller, currency, price, discount, tax, and total.
3. Confirm whether the invoice was issued and paid in the financial system.
4. Record exceptions in the system designated by the organization.
5. Avoid changing participant access solely from an assumption about Transaction status.

Prices, discounts, currency, and tax

The Transaction records the calculation produced by the configuration and checkout context at that time.

Regular price and administrative price

Regular-currency prices come from the Training Activity and enabled platform currencies. In supported administrative enrollment flows, an authorized administrator can specify another amount or choose Free.

For maintaining future activity and Product prices, see Price Manager.

Interpret the historical Transaction from the amount actually recorded—not from the activity’s current price, which may have changed later.

Coupon and organization discounts

A Coupon created under Course Administration → Discount campaigns can reduce the regular Training Activity price by a percentage. An eligible organization discount can also apply.

Where both apply, their percentages are combined for the Training Activity price. The used Coupon and percentage appear in the Transaction details and applicable confirmation or invoice information.

Additional Products

Coupon and organization discounts affect the Training Activity price, not the Additional Product price.

An optional Product bought later from Learn mode creates a separate Product Transaction.

Currency

Use the currency stored on the Transaction when reconciling. Do not convert a historical total using today’s exchange rate or assume that the buyer used the platform’s default currency.

Available activity currencies and the user’s profile context influence the enrollment flow.

Tax

Tax can depend on platform tax rules, seller entity, buyer information, activity format, and activity location. The Transactions Report can expose list price, discount, net price, tax, and total as separate numeric fields.

If tax appears incorrect, investigate the configuration and buyer context that applied when the Transaction was created. Do not infer the correct legal treatment from the activity title alone.

Virtual Credit Transactions

Virtual Credits are an organizational payment mechanism rather than a regular currency.

During a supported enrollment flow:

• The activity must have a Virtual Credit price.
• The participant must belong to an eligible organization or sub-organization.
• The paying organization must be selected where required.
• The organization must have enough Virtual Credits.
• Bulk enrollment applies the same validation to every user.
• Users from different organization contexts may prevent one combined bulk payment selection.

A Coupon cannot be combined with Virtual Credits.

For code models, scope, and usage limits, see Discount campaigns and Coupons.

When reconciling, compare the Transaction with the organization’s Virtual Credit balance and history rather than an external card provider.

Waiting-list Transactions

When the activity has no eligible seat and the user enters the waiting-list flow, the Transaction receives Pending status.

Capacity can be affected by:

• Overall activity Seats
• Seats per organization
• Existing registrations and reservations
• Pending approval processes
• Registration deadlines
• Waiting-list configuration

The Transaction does not reserve a paid seat or override capacity. If a seat becomes available, the waiting-list process determines whether the person is promoted. When the signup is promoted from Waiting list or Reserved to Registered, the Transaction can become Completed.

Before collecting or retrying payment for a Pending Transaction, confirm the current signup and capacity state. Do not assume that a remaining Coupon use, payment authorization, or invoice arrangement creates a seat.

Additional Product Transactions

Additional Products can be Included or offered as Optional purchases alongside Training Activities. Two purchase patterns matter.

Subscription Transactions

Subscriptions extend Transactions beyond one-time Training Activity enrollment. The central Course Administration → Transactions overview can include subscription-related records.

To inspect the payment history for one subscription owner, open Subscriptions, select the subscription owner record, and open Transactions. Do not confuse this with Course Administration → Subscriptions, which manages subscription definitions.

Individual Transaction records can be created for:

• Initial subscription purchase
• Recurring payments
• Seat-quantity changes
• Billing-period updates
• Other supported subscription billing events

Auto-enrollments arising from a subscription can also reference the included Training Activities. Activity start and end fields can be empty where a Transaction spans several activities.

Use the subscription record for entitlement, seats, plan, cancellation, and next billing context. Use the Transaction and provider for the individual payment event.

Reselling Gateway Transactions

In a Reselling Gateway flow, the Storefront activity is a reusable offer from which private deliveries can be initiated.

Once the flow starts, Eurekos creates a temporary clone while the private delivery and signup are being configured. When the initiator completes enrollment, they become the clone’s first signup. The signup and Transaction are connected to the private clone, Self enrollment is disabled on that clone, and the initiator becomes its Contact Manager.

The original offer remains available for later initiations. Each completed initiation can therefore produce a separate private delivery. Look for the final participant and commercial records on the clone, not only on the original Storefront activity.

Where calendar events have been created in Calendar and connected to the original Training Activity, the initiator’s selected dates are retained for the private delivery. These are Calendar events, not Event modules. Webinar links inherited from the template are cleared so the private delivery can receive its own meeting information.

If the initiation is abandoned and the temporary clone has no signups, the scheduled cleanup can remove it after the configured period. A clone containing a valid signup or Transaction must not be treated as orphaned. Cancelling a participant must not by itself delete a clone that still represents a valid private delivery.

Learn more in Reselling Gateway for configuration, invitation matching, Calendar behavior, permissions, and cleanup safeguards.

Resend an enrollment confirmation

Open the individual Transaction and select More → Resend confirmation of enrollment.

Before resending:

1. Verify the recipient and email address.
2. Confirm that the Transaction and signup belong to the same intended activity.
3. Check that the current status still supports the message.
4. Review whether dates, location, price, Product, or cancellation information changed after the original confirmation.
5. Avoid presenting an old order confirmation as proof of a later refund, move, or invoice payment.

Resending helps when the original message was lost or filtered. It does not retry payment, create another signup, repair an incorrect email address, or change the Transaction.

Use Course Administration, Analytics, and integrations for different jobs

Transactions Report filters

The report can be narrowed by:

• Transaction creation period
• One or more Training Activities
• Type: Product, Sign-up, Personal subscription, Team subscription, or Managed subscription
• Customer type
• Payment method
• Status

Only activities that generated Transactions appear in the Activity selector. Available filter values depend on the enabled platform features and the records in scope.

Transactions Report fields

The complete or customized report can include:

• Core IDs, Type, Status, Created, and Changed
• User, email, user ID, and external ID
• Customer type, country, address, and company
• Company registration, VAT, PO, and EAN information
• Activity, Additional Product, and subscription references
• List price, discount, net price, tax, total, and currency
• Activity schedule and signup expiration
• Subscription next billing date
• Invoice PDF and invoice status where enabled

Numeric commercial fields are exported in a finance-friendly numeric format. Confirm decimal and currency handling when importing the report into another system.

Routine reconciliation

Use a consistent reporting period, date definition, organization scope, and documented filters. Decide explicitly whether to include free enrollments, Product purchases, and subscription events; apply the report’s deleted-user and deleted-activity rules when comparing totals. Match records through stable Eurekos and external references, confirm numeric and currency handling, and assign an owner to exceptions such as duplicates, failed payments, refunds, or missing signups. Share and retain exports through the approved process.

Data snapshot behavior

Report fields that describe organization context preserve the context recorded at the time of the Transaction. This matters when a user later changes organization, country, address, or profile information.

Use the historical value to explain the original calculation. Use current profile data only when the question concerns the user’s present state.

API and integrations

The Open API can expose Transactions for ERP, finance, reporting, or other owned systems. A configured CRM integration can also synchronize selected Transaction fields one way from Eurekos.

Define:

• Which system is authoritative for each status
• Which identifier is the cross-system key
• Whether data is pushed, pulled, or scheduled
• How retries and duplicates are handled
• How currency, tax, and numeric fields are mapped
• Which organizational and personal data may leave Eurekos
• How refunds, cancellations, and late changes are reconciled

API availability does not make an integration self-designing. Establish ownership, mapping, monitoring, and exception handling before relying on it for financial operations.

A reliable investigation workflow

Cancellations, refunds, and corrections

Cancellation, access, and payment are separate dimensions. A user leaving an activity does not automatically explain what happened financially, and a provider refund does not by itself describe the participant’s current access.

Use the investigation workflow above to establish the current financial and access states before applying the approved cancellation or refund policy. Check any effects on Additional Products, subscriptions, Coupons, and Virtual Credits. Complete each action in the system that owns it, then verify the final state in both systems.

Do not assume that:

• Cancelling a signup automatically refunds a card payment
• Refunding a provider payment automatically cancels training access
• Cancelling an invoice automatically changes the Eurekos Transaction
• Cancelling an enrollment restores a Coupon use
• Moving a participant creates the same price or payment outcome as a new checkout
• Editing the current activity price rewrites a historical Transaction

Where the configured integration does not automate both sides, these are coordinated administrative actions.

Data protection and audit practice

Transaction records can contain personal, organizational, and financial-context data. Apply the platform’s role and organization controls and the organization’s data-retention policy.

Good practice includes:

• Never asking a participant to send complete card details
• Never storing card details in comments, exports, support tickets, or email
• Sharing provider Reference IDs rather than payment credentials
• Sending exports only through approved secure channels
• Restricting Finance exports to necessary fields and date ranges
• Documenting manual price overrides and Free enrollments
• Keeping a clear cross-system identifier
• Preserving original records rather than silently recreating history
• Verifying user identity before resending order documents

Common operating models

Troubleshooting