How to track customer support credits in GLPI with the Credit plugin
A team that sells prepaid support hours needs GLPI to show what each customer bought, what has been used and what is left. The Credit plugin is the GLPI extension built for that job: it lets you define credit types, issue vouchers to an entity, and deduct credit as technicians work on tasks and solutions. Teams implement it when prepaid support is sold alongside tickets and the balance currently lives in spreadsheets or in a finance tool that technicians cannot see. Before planning the build, confirm the plugin's behavior, publisher and support level from its own documentation, then check where it falls in the GLPI Network plugins vs community plugins guidance, which describes which plugins need a subscription and how support differs for Teclib-published and community plugins. Those answers decide who you call when a deduction is wrong and whether you can rely on a vendor fix. Also confirm which GLPI versions the plugin supports, since no release details for it were supplied for this page.
Everything here runs inside a GLPI instance you operate, so the plugin, its credit data and its upgrades follow the GLPI version in use. Plan the plugin version against the GLPI release before any upgrade, and test the voucher and deduction flow on a copy of the database. The GLPI update procedure requires backing up the database, the files and the config directory, and since GLPI 11.0 plugins are suspended after a new version is detected and must be reactivated after major updates. Ask your implementation partner to include a credit balance reconciliation check in the upgrade test plan, so a version change cannot silently change how remaining hours are calculated.
What the Credit plugin records and enforces in GLPI
The Credit plugin ties a prepaid balance to the customer entity that bought it and to the work that draws it down. The five areas below are the ones to check against the plugin documentation for your GLPI version before you design a sales or billing process around them.
Credit types for different work
A credit type defines what a prepaid balance can pay for, such as a block of support hours or a fixed number of incidents. Separate types let you price remote support differently from on-site visits and report each pool on its own. Confirm how many types you can define, whether a type can be limited to certain ticket categories, and whether a type can be renamed once vouchers have been issued.
Vouchers scoped to each entity
A voucher is the sold quantity of a credit type, assigned to a GLPI entity so that only that customer's tickets draw from it. Entities are how GLPI separates customers, so the scoping decision belongs in the design before the first sale. Confirm whether a voucher can be shared with child entities, how a balance is moved if a customer restructures, and which profiles can create or edit vouchers.
Deductions on tasks and solutions
Consumption is recorded when a technician logs time on a task or when a ticket is closed with a solution, depending on how the plugin is configured. The difference matters because one ticket can hold several tasks before it is solved. Confirm which GLPI item types trigger a deduction, whether the duration comes from each task or from the ticket total, and whether editing or deleting a task reverses the deduction.
Expiry dates on balances
A voucher can carry an expiry date after which its remaining balance should no longer be drawn. Expiry terms are a commercial and accounting decision as much as a software setting, so agree them with finance first. Confirm whether expired balances are blocked, flagged or left available, how expiry applies to partly used vouchers, and whether anyone is warned before a balance lapses.
Over-consumption handling
Over-consumption occurs when logged work exceeds the remaining balance. Your team must decide whether such work is blocked, accepted with a negative balance, or accepted and billed separately. Confirm the exact behavior in your plugin version, whether technicians see a warning before the deduction is saved, and how the overage appears in reports so that it can be invoiced.
Credit types, voucher scope and expiry choices
This table compares the main configuration decisions for a prepaid support credit model in GLPI: how many credit types to define, whether vouchers attach per entity or per contract, how credits expire, and what happens when consumption exceeds the balance. Read each row as a decision to settle before you sell the first voucher, and confirm the listed behavior in the plugin version you run.
| Decision | Options | When it fits a support business | What to confirm in the plugin before committing |
|---|---|---|---|
| Number of credit types | One generic hours type, or several types by service level or work category | One type fits a single support tier sold as a block of hours. Several types fit firms that price remote administration, on-site work or senior engineering differently. | Whether a task or solution can draw from a specific credit type, and how a ticket is charged when more than one type could apply. |
| Meaning of each credit type | Hours, monetary value, or units defined per service level | Hours are easiest to explain to customers. Monetary value suits mixed rates but needs a rule for converting time spent into currency. | What unit the balance is stored in, and whether rounding of time entries is applied before deduction. |
| Voucher scope | Per entity, so each customer organization holds its own balance | Fits businesses where each customer entity buys and consumes its own hours, and where invoices follow the entity. | How entity hierarchy is handled, and whether child entities can consume credits bought by a parent. |
| Voucher scope | Per contract or per purchase order | Fits customers who buy several blocks over time under different agreements, each with its own terms. | Whether a voucher can be linked to a contract record, and how a contract end date interacts with the voucher balance. |
| Expiry approach | Fixed expiry date on each voucher | Fits prepaid blocks sold for a defined period, such as an annual support package. | How the expiry date is set, whether it can be edited after sale, and what happens to unused balance on that date. |
| Expiry approach | Rolling expiry measured from purchase or first use | Fits retainers where each block should last a set period from the day it is activated. | Whether expiry is computed from creation or from first deduction, and whether this is configurable per credit type. |
| Expiry approach | No expiry | Fits long-running relationships where unused hours carry forward, but adds liability that finance must track. | Whether the plugin allows a voucher without an end date, and how finance reports outstanding balances. |
| Over-consumption | Block the deduction when the balance is empty | Fits businesses that sell only what customers have paid for and want a hard stop on unpaid work. | Whether a task or solution is refused, or saved with a warning, when the balance is insufficient. |
| Over-consumption | Allow the overage and bill it separately | Fits teams that prefer not to interrupt a support engagement and invoice the excess afterward. | How the excess is recorded, whether it appears on reporting, and which rate or document is used for the overage. |
Over-consumption rules by billing model
This model fits agreements where support stops once the prepaid hours are used up until the customer buys more. Technicians need to know before they start work whether the entity still has enough balance, because a block discovered mid-ticket creates the worst conversation with a customer. Account managers own the top-up conversation, so they need a clear view of remaining balance and the expiry date of each voucher.
- Technician view: confirm how a technician learns that a balance is insufficient, and whether the block stops a task from being saved, a solution from being recorded, or only shows a warning.
- Account manager view: check which balance figures appear on the entity and whether they can be filtered by credit type and expiry date.
- Finance reporting: plan a report of blocked attempts, if the plugin records them, so that lost work is visible rather than silently delayed.
- Emergency work: decide with the customer who can override a block for incidents, and confirm whether the plugin supports an override that is logged.
- Before go-live: test a task that would exceed the balance, a solution that would exceed it, and a voucher that expires during an open ticket.
Ask for a written test script covering each of these cases on a non-production copy before you rely on the block in front of customers.
This model fits agreements where the prepaid hours cover a base level of support and any further work is invoiced at the end of the period. The plugin's job is to record that work beyond the balance was done and to show exactly which tasks and solutions fall outside the prepaid pool. Finance depends on that separation, so the record of overage has to be as reliable as the record of consumption.
- Technician view: confirm whether technicians are told that work is now billable, and whether that message appears before or after the time is logged.
- Account manager view: confirm how overage is shown on the entity, so that a customer question about an invoice can be answered from GLPI.
- Finance reporting: agree a monthly export of overage lines per entity, with ticket references, dates and the technician who logged the work.
- Disputes: keep the original task text and timestamps unchanged, because invoices will be checked against them.
- Before go-live: confirm whether overage is stored as a separate figure or derived from the balance, and how a later voucher is applied against earlier overage.
Confirm the exact fields the overage export contains with your finance team before the first billing cycle.
This model fits agreements where the customer may go below zero during a period and the negative balance is settled when the next voucher is bought or the contract renews. Technicians keep working without interruption, which is the main commercial reason for the arrangement. The risk moves to the reporting side, because a negative balance can persist for months if nobody watches it.
- Technician view: confirm that a negative balance does not block tasks or solutions, and that technicians can still see the customer's remaining position when they open a ticket.
- Account manager view: set a routine review of entities with a negative balance, so renewal conversations start with a known figure.
- Finance reporting: plan a report of negative balances at each period close, including the amount, the entity and the date it went negative.
- Renewal settlement: confirm how a new voucher offsets an existing negative balance and whether the offset is visible on the entity afterwards.
- Before go-live: test a task that drives the balance below zero, then add a voucher and check the resulting balance and any expiry dates on the vouchers used.
Write down the maximum exposure your organization accepts per customer and confirm with the plugin's behavior whether that limit can be monitored, since the plugin does not stop the overdraft.
Implementation sequence for a prepaid hours program
This sequence takes a prepaid support hours model from a compatibility check in a test copy to a live rollout, with a written rules sheet, test evidence and a reconciled balance report kept at each stage. It is designed so that billing rules are settled before any voucher is issued to a customer.
Confirm GLPI and plugin compatibility in a test copy
Clone the production database and files into a separate test instance, then check the GLPI version in use against the plugin release you intend to install. Confirm the PHP and database versions against the GLPI prerequisites, and follow the update procedure's backup rules so the test copy matches production as closely as possible. Keep the compatibility record, including the exact GLPI and plugin versions tested, as the first item in your change file. The step is complete when the plugin installs, activates and loads its menus on the test instance without errors in the logs.
Define credit types and billing rules in writing
Work with the service delivery owner and finance to decide what each credit type represents, such as a block of support hours at a given service level, and which ticket categories consume it. Write down the rules for deduction on tasks versus solutions, how over-consumption is billed, how expiry is handled and who approves exceptions. Ask the vendor or your own administrators to confirm exactly which deduction triggers the plugin supports before you commit to a rule. The output is a signed rules sheet that both the service desk and finance accept as the reference for every later test.
Create entities and vouchers for a pilot group
In the test instance, set up the entities that represent the pilot customers, then create credit vouchers for each one using the credit types from the signed rules sheet. Use a small, representative set of customers, including at least one with an expiry date and one without, so both paths are exercised. Record each voucher's entity, type, quantity and expiry in a voucher register. The step is complete when every pilot entity shows the balance it should carry on the day the vouchers were issued.
Run deductions on test tickets through tasks and solutions
Open test tickets for the pilot entities and log work through tasks, then close them through solutions, checking the deduction after each action. Repeat the same scenario for tickets that are reopened, edited or cancelled to see how the balance responds. Compare each balance change with the expected value in the rules sheet and log any mismatch as a defect. Keep the completed test log with ticket numbers, actions, expected and actual balances, because it becomes the evidence that the deduction logic matches the agreed billing rules.
Validate expiry and over-consumption behavior
Set test vouchers to expire and then run work across the expiry date, confirming that unused hours are no longer available and that the report shows them correctly. Next, drive a pilot entity past its balance and check that the over-consumption rule from the rules sheet is applied, whether that means blocking, flagging or recording the excess for billing. Ask your administrators to confirm how the plugin reports expired and excess hours, since the outcome depends on this configuration. The step is complete when each expiry and overage case in the test log has a documented result that matches the signed rules.
Reconcile balances against finance records
Export the balance report for the test entities and compare every remaining balance with an independent calculation built from vouchers issued, hours deducted, expired and billed. Investigate any difference until the cause is known, whether it is a configuration issue, a process gap or a test error. Have finance sign off the reconciled report as the baseline for production. This reconciled balance report is the most important output of the sequence, since it shows that the system and the billing records tell the same story.
Roll out to production and train technicians
Apply the same plugin version and configuration to production using the update and backup procedure, then recheck that plugins are reactivated after any version change. Issue vouchers to the first production customers only after the reconciliation is signed, and monitor the first balance report against the baseline. Train technicians on deduction timing, how to read a balance, and the escalation path for disputed hours, then record attendance and the training material version. The rollout is complete when production balances match the signed baseline for the first cycle and technicians have acknowledged the rules sheet.
What drives effort and cost in a credit setup
This table lists the factors that change how much work a GLPI Credit setup takes and what each one should be checked against in a quote. Read each row as a question to settle before the scope is written, since the cost components are set by the written scope rather than by any fixed rate.
| Driver | Why it changes effort | How to keep it down | What to ask for in a quote |
|---|---|---|---|
| Number of credit types | Each type carries its own unit, validity and deduction rules, so every type needs configuration and testing. | Limit types to products you actually sell, such as support hours by tier, and reuse one type where terms match. | A list of credit types with units, validity rules and the ticket types each one may deduct from. |
| Number of entities and contract variants | Credits are scoped per entity, so each customer contract variant can multiply vouchers and checks. | Group customers that share terms and define variants once in a template rather than per customer. | How many entities and variants are in scope, and whether vouchers are created by the partner or by your staff. |
| Ticket types that should deduct | Every task and solution type that consumes credit must be mapped and tested, including edge cases like internal work. | Decide early which ticket categories are billable and exclude internal or warranty work explicitly. | The list of ticket types and task categories that deduct, and the test cases covering each. |
| Historical prepaid sales to migrate | Past balances, expiry dates and consumed hours must be reconciled before go-live, and mismatches are costly to correct later. | Export a clean balance sheet per customer and migrate only open balances, with past consumption recorded as a single adjustment. | Whether migration covers history or only open balances, and who signs off on reconciled totals. |
| Custom fields or workflows touching deductions | Custom fields, forms or automated actions that change ticket state can alter when a deduction runs and must be checked against it. | Keep deductions tied to a single documented trigger, and review existing workflows before the build starts. | An inventory of custom fields, rules and automatic actions that interact with credit and how each will be tested. |
| Approval steps for manual adjustments | Corrections, goodwill credits and expiry extensions need an approval path, and each path adds roles, notifications and audit checks. | Use one approval level for most adjustments and reserve a second level for large or retroactive changes. | The approval matrix, who approves each adjustment type, and how approvals are recorded for audit. |
| Expiry and over-consumption rules | Expiry handling and rules for tasks that exceed the remaining balance each need explicit decisions and test scenarios. | Agree the expiry policy and over-consumption behavior in writing before configuration starts. | Written expiry and overdraw rules, and the scenarios the test plan will cover before go-live. |
How credits connect to tickets, contracts and billing
Prepaid support hours only mean something when they line up with the tickets people work, the contracts and entities that own them, and the rules that define what an hour covers. Each card below names one connection, the dependency behind it, and what to confirm in your own GLPI configuration and the Credit plugin documentation before you sell a single voucher.
Ticket tasks and solutions
Credit deduction happens when technicians record time on ticket tasks and close work with a solution, so the deduction rule is only as reliable as the data entered there. Confirm which task and solution events the plugin reacts to, whether time is taken from actiontime or from a separate field, and what happens when a task is edited or deleted after deduction. Test a reopened ticket, because a second solution can deduct twice if the plugin does not track the earlier one.
Contracts and entities
Vouchers are issued per entity, so a customer's credits must sit under the entity that owns their tickets and assets. Check that child entities inherit or do not inherit balances as you intend, and that a contract linked to a credit type does not point at the wrong customer after an entity is moved or renamed. Map this structure before you create the first voucher, since correcting entity ownership later changes the audit trail.
SLAs and OLAs
An SLA or OLA defines response and resolution targets, but it does not define what a support hour covers. Decide with the customer which ticket categories, priorities and service levels consume credits, and whether out-of-hours work deducts at the same rate. Confirm how the Credit plugin reads ticket category and priority, because a rule based on a category that technicians can change will drift over time.
Reporting and finance exports
Finance teams need balances, consumption and expiry dates they can reconcile against invoices, not screenshots of ticket history. Ask which reports and exports the plugin provides, which fields they include, and whether they can be filtered by entity and period. Reconcile a sample month by hand against the ticket records before you rely on the figures for billing, and keep the export format stable across GLPI upgrades.
Profiles and access rules
Profiles and entity rights decide who can see a balance, who can add time to a ticket and who can edit a voucher. A requester in one customer's entity must never see another customer's remaining hours, and a technician should not be able to raise their own credit balance. Test each profile with a real login in a staging instance, and record which rights were changed for the Credit plugin so they can be checked after each upgrade.
Plugin reactivation after upgrades
GLPI 11 suspends plugins after a new version is detected, and they must be reactivated after major updates. A suspended Credit plugin stops deducting hours silently, so balances can drift while tickets keep closing. Schedule a re-test of deductions, vouchers, expiry and exports in every upgrade window, and compare balances against a known ticket set before and after the update.
Questions teams ask before setting up credit tracking
Can our team set up GLPI credit tracking without an implementation partner?
Often yes, if you have someone who can administer GLPI, manage the database and web server, and test changes in a non-production copy first. The harder part is usually agreeing the business rules: which credit types exist, how vouchers map to entities, and what happens when hours run over. Those decisions need finance and service management sign-off before any configuration. A partner adds value mainly when the rules are complex, the instance is shared across entities, or the team has no spare capacity for testing. Confirm the plugin's current installation requirements against your GLPI version before you start.
What drives the cost and effort of a credit tracking setup?
The main drivers are the number of credit types, how many customer entities hold prepaid balances, and how deductions are triggered on tasks and solutions. Effort also grows with reporting needs, data cleanup for existing customers, and the number of approval or review steps finance requires. Costs are mostly one-time for design, configuration and testing, plus recurring effort for maintenance and upgrades. Ask any provider for a written scope listing the credit types, entity count, deduction rules, test cases, and who signs off on each. Compare quotes against that same scope, not against headline day rates.
How long does a pilot usually take?
A pilot's length depends on how many rules need to be settled before configuration starts, how many entities take part, and how quickly finance and service management can review test results. Teams that have agreed their credit rules in advance usually move faster than teams still debating expiry and over-consumption policy. Ask for a timeline tied to named milestones, such as rule sign-off, test environment build, a limited entity rollout and review. Avoid fixed durations that are not based on your own scope. Your pilot plan should also state what success looks like before any real customer balance is touched.
What do finance and service management need to provide?
Finance needs to define credit types, pricing or hour value, expiry rules, and how unused balances are treated in reporting. Service management needs to confirm which ticket types, tasks and solutions consume credit, who may approve exceptions, and how customers are told about their balance. Both teams should review a sample set of tickets and deductions during testing. Without these decisions, the configuration will encode assumptions that nobody has checked. Write the rules down in a single document that both teams approve before build work starts.
Does the credit plugin require a GLPI Network subscription?
Confirm this before you plan the budget. The GLPI Network subscriptions page lists public cloud, private cloud and self-hosted subscription tiers, and the level you need depends on which plugins you run and the support you want. Plugins can be supported by Teclib' or maintained by the community, and support expectations differ between them. Check the plugin's own documentation and the Teclib' plugin listing for its current license and support status, and ask your provider to state which subscription, if any, the design assumes.
How do GLPI upgrades affect the credit plugin?
Plugins need attention during every GLPI update. The update procedure requires a backup of the database, files and config directory including glpi.key and glpicrypt.key, then replacing application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Confirm that a compatible plugin version exists for your target GLPI release before you upgrade, and test deductions, balances and expiry jobs in a copy of production. Plan this step into your upgrade schedule rather than treating it as an afterthought.
How should we handle customers who already hold prepaid hours?
Existing balances need a documented opening position before the plugin goes live. Export each customer's remaining hours, agreed expiry dates and any open tickets that have partly consumed credit, then reconcile those figures with finance's records. Load balances as vouchers per entity so history remains traceable, and decide whether pre-existing tickets are deducted retroactively or only going forward. Test a few representative customers end to end, including one with a balance near expiry and one with an overrun. Keep the reconciliation report as evidence for finance.
How DeployOpen scopes and delivers GLPI credit tracking
DeployOpen plans, implements, customizes, tests, documents and supports self-hosted open-source platforms inside your own infrastructure, including GLPI. For prepaid support hours tracked with the GLPI Credit plugin, we start from your sales terms and how your technicians log time, then agree the design in writing before any build begins.
How we scope
- We map the credit types, voucher rules and entity structure you sell against before choosing configuration.
- The written scope lists which tasks and solutions deduct credits, and which entries stay outside the balance.
- We record expiry dates and over-consumption rules as explicit decisions your finance and support leads approve.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We configure credit types and per-entity vouchers in a test instance that mirrors your GLPI version and database.
- Deduction logic on tasks and solutions is checked with scripted test tickets covering partial and full consumption.
- Expiry and over-consumption behavior is verified against the signed rules, including edge cases around renewals.
- Plugin compatibility is confirmed against your GLPI release before any change reaches production.
How we hand over
- You receive configuration documentation covering credit types, vouchers, deduction points and expiry settings.
- A written runbook explains how support staff check a balance, correct an entry and escalate a disputed deduction.
- Test cases and results are delivered so your team can repeat the verification after future changes.
- Knowledge transfer sessions cover administrators and the staff who will handle customer balance questions.
How we support
- Ongoing support, upgrades and plugin maintenance are available as a retainer after handover.
- Retainer scope covers GLPI and plugin upgrades, including re-testing credit deductions against each new version.
- Ask us to confirm which GLPI and plugin versions the Credit plugin supports before you commit to a timeline.
- We document any local changes so the credit logic stays understandable to your next administrator.
