Custom inventory software with explainable stock movement

AI Inventory Management Software Built Around Your Stock

Describe your SKUs, locations, stock events, roles, import rules, and recovery process. Playcode builds the browser workflow, server logic, and database-backed ledger together so your team can test every receipt, issue, transfer, adjustment, retry, conflict, and repair before relying on the balance.

No credit card required · No coding needed

Quick answer

What should AI inventory management software keep consistent?

AI inventory management software should keep every SKU-and-location balance traceable to receipt, issue, transfer, and adjustment records. With Playcode, you define roles, validation, retry identity, concurrent decrement behavior, imports, exports, reconciliation, audit, and repair, then build a custom stock workflow your team can test and operate.

1.1M+users
26M+projects
Since 2016

Used by people at

Counts registered accounts using corporate email domains from the companies above. Playcode is a self-serve product, not a contracted vendor to these brands.

From Stock Rules to an Auditable Inventory App

Prove one SKU across two locations before adding more operational scope

01

Define the Ledger and Stock Rules

Name each SKU, location, unit, starting balance, and actor role. Decide which events may increase or decrease stock, who can adjust a count, whether negative inventory is ever allowed, and which record is authoritative when a screen disagrees.

Keep each stock transaction immutable with a stable ID, actor, reason, timestamp, and directional entry per affected location. Treat the displayed balance as a materialized result that can be reconciled from those entries.

Preview
AI Chat
Publish
I'm a realtor in Miami. I need a website to show my listings and get buyer leads.
4 Questions
2 / 4
What's the main style for your real estate site?
AModern & minimal with clean lines
BLuxury feel with large property photos
CProfessional & corporate
DI'll describe my own style below
Or type your own answer...
Skip
Next
Describe what you want to change...
Economy
Build Progress
4/6
✓
Site layout & navigation
3s
✓
Hero section with CTA
5s
✓
Property listings grid
8s
Building contact form...
About page & bio
Footer & SEO meta
miami-homes.playcode.io
Miami Dream Homes
Your trusted partner in Miami real estate
Search by neighborhood...
Featured Listings
NEW
$1,250,000
Coral Gables Villa
4 bd|3 ba|2,400 sqft
OPEN
$890,000
Brickell Condo
2 bd|2 ba|1,200 sqft
Get in Touch
02

Build the Transaction and Access Boundary

Ask Playcode to build server-authorized receipt, issue, transfer, and adjustment actions. Give one logical attempt one request ID and safe fingerprint, return the original result for an exact retry, and reject changed content under the same identity.

Use record versions or an equivalent transactional guard for concurrent decrements. A retry after a lost response and two operators requesting the final unit are different problems and need different outcomes.

03

Import, Reconcile, Publish, and Recover

Preview a fictional opening-balance import, reject duplicate or unknown rows before any write, and export only the fields an authorized role needs. Recalculate balances from transaction entries and lock new writes when recovery finds a mismatch.

Publish over HTTPS, test two ordinary accounts, the last-unit race, retry conflicts, an authorized export, reconciliation, record repair, and whole-app recovery decisions before real stock records enter the app.

Your website is live!

https://
miami-homes.playcode.io
Site is secure - SSL certificate active
Or connect your domainmiami-dream-homes.com
Miami Dream Homes
Your trusted partner
Miami Dream Homes
Your trusted partner
Replace editable totals with accountable movement

Make Every Balance Explainable by Its Stock Events

A trustworthy inventory app can answer what changed, where, why, and by whom

A mutable quantity in a sheet

  • One total hides which location physically holds the stock
  • A correction overwrites the prior value and its reason
  • A double-click or weak connection applies the same issue twice
  • Two operators can both believe they claimed the final unit
  • A backup restores quantities without retry or audit identity

A bounded stock transaction ledger

  • Each SKU/location balance derives from directional transaction entries
  • Receipt, issue, transfer, and adjustment have distinct rules
  • Exact retries return the original result and changed reuse fails
  • Concurrent decrements preserve the no-negative-stock constraint
  • Import, export, reconciliation, audit, repair, and recovery stay distinct
A dependable first inventory release

What Your Custom Inventory App Can Include

Start with the smallest ledger that can explain every on-hand quantity

01

SKU and location balances

Give each stock item and storage location a stable identity, explicit unit, current quantity, record version, and last-change time.

02

Four stock transaction types

Model receipts, issues, transfers, and positive or negative adjustments as durable records with actor, reason, time, and location entries.

03

Role and action controls

Protect read, write, adjustment, import, export, reconciliation, audit, and repair paths on the server for viewer, operator, manager, and administrator roles.

04

Retry and concurrency safety

Use one request identity and fingerprint for a technical retry, while version or transactional checks protect the final unit from concurrent decrements.

05

Import, export, and reconciliation

Validate an opening batch before applying it, keep row outcomes reviewable, authorize exported fields, and compare materialized balances with the transaction ledger.

06

Audit, repair, and recovery

Record attributable events, lock writes on a recovered mismatch, repair one balance from authoritative entries, and preserve request identity through recovery.

A practical inventory implementation guide

Build One Stock Ledger the Team Can Reconcile

Define identities, movements, authority, retries, imports, and recovery before adding more locations or integrations.

Before you build

Prerequisites

  • A written SKU, location, unit, and transaction contract

    A quantity has no stable meaning without the stock item, physical or logical location, unit, transaction type, direction, actor, reason, and time that produced it.

    Ready when: For one fictional SKU at two locations, the team can name the identifiers, unit, allowed receipt, issue, transfer, and adjustment fields, no-negative-stock rule, and which transaction entries produce each balance.

  • A role and action matrix enforced on the server

    Signing in or hiding an adjustment button does not decide who may issue stock, import opening balances, export a ledger, reconcile a mismatch, or repair a record.

    Ready when: Expected outcomes are written for a signed-out visitor, viewer, two operators, manager, and administrator across balance, transaction, adjustment, import, export, audit, reconciliation, and repair actions.

  • A controlled opening-balance import and reconciliation baseline

    A spreadsheet import can duplicate a SKU/location row, use an unknown unit, overwrite active stock, or partially apply before a later row fails.

    Ready when: A fictional file has stable source-row keys, unique SKU/location pairs, integer quantities, known identifiers, expected row results, an approval owner, and hand-calculated totals for the first reconciliation.

  • Separate policies for export, record repair, and whole-app recovery

    Exporting authorized stock data, correcting one materialized balance, and restoring code, files, and database to a saved point have different blast radii and owners.

    Ready when: The runbook names export fields and roles, repair evidence and version checks, saved-point timing, post-checkpoint transaction review, recovery owner, and the test that proves old request identities still reject duplicates after recovery.

Implementation sequence

Do, observe, verify
  1. 01
    Playcode AI prompt and project database model

    Model the stock ledger and materialized balances

    Create stable SKU, location, actor, stock transaction, transaction entry, request identity, balance, import batch, export, reconciliation, and audit records. Keep directional ledger entries immutable and materialize the current SKU/location quantity with a version.

    Expected result

    Every displayed balance can be recalculated from durable entries, and receipt, issue, transfer, adjustment, import, export, reconciliation, and audit no longer share one ambiguous record or status.

    Verify

    Start one fictional SKU at zero, receive 20, issue 3, transfer 5, adjust the destination by -1, and confirm the ledger derives 12 at the source and 4 at the destination.

  2. 02
    Server receipt, issue, transfer, and adjustment handlers

    Validate and authorize every transaction on the server

    Resolve the current actor and role, validate bounded identifiers and integer quantities, require an adjustment reason, reject unknown SKUs and locations, prevent same-location transfers, and preflight every entry before committing the transaction and audit event.

    Expected result

    Viewer writes, operator adjustments, malformed quantities, unknown records, negative results, and half-applied transfers all fail without changing balances or creating misleading success events.

    Verify

    Replay each invalid request with known IDs, inspect the raw result, then compare transaction count, affected balance versions, and audit count before and after the request.

  3. 03
    Request boundary and transactional database write

    Separate technical retries from concurrent stock claims

    Scope one request ID to one stock action and store a safe fingerprint with the durable result. Return that result for an exact retry and reject changed reuse. Use a version, row lock, conditional update, or equivalent transaction for decrements and transfers.

    Expected result

    A double-click or interrupted response applies once, while two operators racing for one remaining unit produce one success and one explicit insufficient-stock or version-conflict result.

    Verify

    Repeat one receipt exactly, change its quantity under the same request ID, and launch two issue requests against a balance of one. Confirm one transaction, one final-unit issue, zero stock, and no negative quantity.

  4. 04
    Protected import preview, export route, and reconciliation job

    Import, export, and reconcile as bounded operations

    Validate all opening rows before writing, reject duplicate SKU/location pairs, preserve a stable batch identity, and return the original batch result on retry. Authorize export fields and recompute expected balances from ledger entries without trusting the materialized quantity.

    Expected result

    An accepted batch applies once, a bad later row cannot leave partial opening stock, exports remain role-scoped, and the reconciliation report names each expected-versus-actual mismatch precisely.

    Verify

    Import two fictional rows, retry the batch, reuse the batch ID with changed content, attempt export as an operator, then compare the manager export and reconciliation totals with a hand calculation.

  5. 05
    Published HTTPS app and protected operator runbook

    Publish, monitor, repair, and rehearse recovery

    Publish the bounded workflow, log stable request, transaction, reconciliation, and audit IDs without private payloads, and run the role and race matrix. Recover a controlled snapshot, lock writes on a mismatch, repair only the affected materialized balance from authoritative entries, and reconcile before unlocking.

    Expected result

    Operators can diagnose stock movement without sensitive logs, a recovered inconsistency cannot accept new writes, bounded repair preserves legitimate transactions, and prior request identities still reject duplicates.

    Verify

    Use two fictional accounts in private browser sessions, export the fixture, alter one controlled materialized balance, recover, verify the lock, repair at the expected version, reconcile, replay a prior request, and document the whole-app saved-point tradeoff.

Decisions that change the build

Should on-hand quantity be authoritative or derived from stock transactions?

  • Store only a mutable on-hand quantity
  • Keep immutable transaction entries and a reconciled materialized balance

Choose: Keep the transaction entries authoritative and materialize the balance for fast reads. Reconcile the materialized value against the ledger and repair only from reviewed entries.

Tradeoff: A mutable quantity is simpler at first but loses causality and makes retries, audit, and recovery ambiguous. A ledger adds transaction and reconciliation work but makes each balance explainable.

Who should be allowed to adjust counted stock?

  • Any operator can enter an adjustment
  • Managers or administrators adjust with a required reason

Choose: Start with manager or administrator adjustment authority, require a reason, and retain the previous balance, positive or negative delta, actor, and audit event.

Tradeoff: Broader authority can speed physical counts but increases accidental and unexplained corrections. Tighter authority adds a handoff but protects the ledger when a count differs.

Should imports set opening balances or update active stock continuously?

  • Opening-balance import into unused SKU/location records
  • Ongoing imports that create explicit stock transactions

Choose: Use opening-balance import only for unused records in the first release. Add ongoing import later as explicit receipt, issue, transfer, or adjustment transactions with mapping, review, and row-level outcomes.

Tradeoff: Opening-only import has a narrow safe boundary. Ongoing import reduces manual entry but needs source ownership, stable row identity, duplicate policy, conflict handling, and reconciliation with activity inside the app.

Before you share it

Test checklist

  • Happy path

    Receive 20 fictional units, issue 3, transfer 5 to a second location, adjust that location by -1, export the ledger, and reconcile both balances.

    Expected: Four attributable transactions produce 12 units at the source and 4 at the destination, the authorized export matches, and reconciliation reports no discrepancy.

  • Invalid input

    Attempt a viewer write, operator adjustment, unknown SKU, unknown location, fractional quantity, same-location transfer, negative result, duplicate import row, and unauthorized export.

    Expected: Every request fails closed with a specific error and no partial balance, transaction, import, export, or success-audit change.

  • Duplicate or retry

    Repeat an exact receipt, reuse its request ID with a changed quantity, retry an opening batch, and race two operators for the final unit.

    Expected: Exact retries return prior results, changed identity reuse is rejected, imports remain single, one decrement succeeds, one fails explicitly, and stock stays at zero rather than negative.

  • Published smoke test

    On the published HTTPS app, use private sessions for two fictional accounts to run read, receipt, issue, transfer, adjustment, import, export, audit, reconciliation, recovery lock, repair, and replay checks.

    Expected: The intended roles complete only their allowed actions, another account stays isolated, all balances reconcile, a recovered mismatch blocks writes, and a repaired ledger preserves prior retry decisions.

If something goes wrong

Common failure cases

The same receipt or issue appears twice after a slow response

Likely cause
The retry received a new request ID, or the server saved the stock transaction before persisting its request identity and fingerprint.
Check
Compare request IDs, safe fingerprints, transaction IDs, actor, SKU, location, quantity, and response timing without logging private payloads.
Fix
Reuse one request ID for the logical attempt and persist its fingerprint and result in the same durable boundary as the stock transaction.

Two operators both issued the final unit

Likely cause
Each request read the old quantity before either write committed, and the decrement had no transactional condition or record-version guard.
Check
Inspect starting balance version, both request and transaction IDs, commit order, affected rows, and the condition used by the decrement.
Fix
Make the non-negative constraint authoritative in the transaction, update only from the expected version or locked row, and retain the final-unit race test.

A transfer removed stock from one location but did not add it to the other

Likely cause
The debit and credit entries committed separately, or validation ran after the first entry changed the balance.
Check
Find the transfer ID, inspect both expected entries and their commit boundary, then compare source and destination versions with the audit event.
Fix
Preflight both locations and commit both directional entries, both balances, the transaction, and its audit fact together or apply none of them.

The displayed quantity differs from the exported transaction history

Likely cause
A materialized balance was edited directly, an import partially applied, or a prior recovery omitted entries or replay identities.
Check
Recalculate the SKU/location balance from directional transaction entries and compare expected quantity, actual quantity, version, import batch, and recovery source.
Fix
Lock new writes, identify the bounded cause, repair only the materialized balance from reviewed entries, reconcile, and unlock after the report is clean.

An opening import duplicated stock or overwrote active balances

Likely cause
The batch had no stable identity, repeated a SKU/location pair, or treated an active record as an unused opening balance.
Check
Inspect batch ID, fingerprint, source-row keys, duplicate pairs, current versions, row results, and whether every row validated before the first write.
Fix
Preview and validate the complete batch, require unique pairs and unused records, persist row outcomes, and return the prior result for an exact batch retry.

Recovery permits an old stock request to apply again

Likely cause
The recovered data restored balances and transactions but omitted durable request identities, fingerprints, results, versions, or audit ordering.
Check
Compare pre-recovery and recovered request records, transaction IDs, balance versions, audit events, and the result of replaying a known request.
Fix
Recover operational identity with the ledger, lock on reconciliation mismatch, and require retry, changed-reuse, and final-unit tests after every recovery change.
Picture stock movement before the interface

One Ledger Can Connect Every Location and Audit Check

The conceptual map keeps stock compartments, movement paths, an audit trail, and reconciliation in one restrained operating view.

Illustrative inventory ledger concept with three storage rows, directional stock movement paths, audit ticks, and a reconciliation check
Illustrative conceptIllustrative process concept, not a Playcode product screenshot. It contains no real inventory records and does not prove barcode, device, provider, ERP, WMS, fulfillment, or forecasting behavior. The actual result depends on your stock model, roles, rules, tests, and brief.
One ledger contract, different stock operations

Custom Inventory Workflows for Teams With Specific Rules

Change the stock model without weakening identity, access, or audit

Workshop Parts

Know what was received and issued

Track parts by SKU and storeroom, require reasons for adjustments, and keep every issue linked to an authorized operator and durable transaction.

Studio Supplies

Move shared materials deliberately

Receive deliveries, issue consumables, transfer stock between rooms, and reconcile physical counts without overwriting the movement history.

Field Equipment Depots

Keep depot balances separate

Represent each depot as a location, apply role-scoped transfers, and investigate a mismatch with transaction IDs rather than one global total.

Event and Project Stock

Audit temporary location changes

Move bounded fictional stock into a temporary project location, return it through explicit transactions, and close only after reconciliation.

Same-release deterministic proof

Run the Inventory Ledger Contract Locally

The downloadable provider-neutral fixture has no runtime dependencies or network calls. Its ZIP SHA-256 is 826536678beee849f2618a9237d1d26788c956b24ca9ef14a60a31b8cd2d741d. The illustration above is context, not evidence.

18/18 tests
deterministic ledger and archive checks passing
4 movements
receipt, issue, transfer, and bounded adjustment
1 final unit
two concurrent decrements produce one safe winner

Download the tested inventory ledger ZIP

Choose the smallest system that fits the stock job

Spreadsheet, Packaged Inventory Tool, or Custom App?

Build custom software only when your records, roles, transactions, or recovery rules need it.

Operational needSpreadsheet or packaged inventory toolPlaycode-built inventory app
A small trusted team edits a simple countA spreadsheet may remain the quickest maintained choiceBuild only when transaction history or access removes meaningful risk
The workflow matches a maintained inventory productA packaged tool may offer faster setup and established operationsUseful when standard records or screens create repeated workarounds
SKU, location, role, and adjustment rules are specificMay depend on conventions, add-ons, or plan-level configurationBuild the exact records, actions, permissions, and operator views needed
Retries and concurrent decrements need explicit outcomesBehavior depends on the selected product and configurationDefine request identity, fingerprints, transactions, versions, and errors directly
The team owns import, audit, repair, and recoveryUse the provider export, support, and recovery contractOperate the custom ledger, bounded export, reconciliation, logs, and runbook
The engine

A software team in one agent

Playcode AI runs the same frontier models that power ChatGPT and Claude - and orchestrates them like a team: it plans the work, delegates to sub-agents, runs long jobs in the background, and reviews its own changes.

Every frontier model

The latest models from every major lab, in one picker. Switch anytime.

ClaudeGPTGeminiGrok

Sub-agents

Big jobs split across specialists - one explores your code, one writes, one audits - working in parallel.

Background tasks

Long builds and migrations keep running while you keep talking. They report back when done.

migration - running

It sees your designs

Have a design in Figma? Paste a screenshot - or a page you like, or a bug - and it builds from what it sees.

Tuned by years of iteration to write production software - structured, typed, maintainable - not throwaway prototypes.

Production code

Real code you can open, read, and edit

Under every project is a codebase the agent keeps production-grade. And you are never locked out of it: open the file explorer and edit any file yourself - server included. No AI required.

Quality is the default

Complete states, secure boundaries, structured code - the bar is what a professional agency would ship.

Every file is yours to open

Browse the whole project - frontend, backend, configuration - and edit directly in the built-in editor.

Developers are welcome

Invite your developer with the right role, or export the project code and files. Nothing is trapped in Playcode.

For teams and organizations

Share it like you share a doc

Playcode is built for organizations, not just solo builders. Workspaces hold your projects, people, and billing; roles and teams decide exactly who sees what.

Workspaces with their own billing

Create a workspace per company, client, or department - each with its own members, projects, and subscription.

Three clear roles

Admins manage, editors build, viewers watch. Set roles on the whole workspace, on a team, or on a single project.

Teams that scope access

Group people into teams and give each team its own projects - or a whole folder of them. Private projects stay private, even inside a shared workspace.

Share outside the workspace

Send a project to any email - a client, a contractor - with exactly the access you choose. No extra seat needed.

Share "Inventory tracker"
Acme Ops workspace
Private
client@partner.co
Editor Invite
Operations team
8 people
Editor
MK
Maya Kowalski
maya@acme.co
ADMIN
JR
Jon Reyes
jon@acme.co
EDITOR
LS
Lena Sato
lena@acme.co
VIEWER
Restricted - only people invited can open it
Real-time

Multiplayer by default

Work on one project together. Write in the same AI chat together. Every message, edit, and setting is fully synchronized - live, for everyone, on every device.

acme-launch · Playcode
MKJR
Maya's laptop
Maya
Add a 'Book a call' button to the hero
Jon
And link it to our calendar, please
Playcode AIDone - button added to the hero and linked to your calendar.Preview updated
Describe the next change...
Jon's phone
Maya
Add a 'Book a call' button to the hero
Jon
And link it to our calendar, please
Playcode AIDone - button added to the hero and linked to your calendar.
Message...
Already there. No refresh.

Same project, same moment

Everyone works in the project at the same time - even in the code editor - without lock-outs or "who has the latest version".

Every device

Start on the laptop, check from your phone: the same live state follows you everywhere you sign in.

Nothing to refresh

Changes arrive over a live connection the instant they happen. Reloading the page is a habit you can drop.

Feels instant

It never makes you wait

Instant

Every click applies immediately on your device. Syncing happens behind you, not in front of you.

Offline

Connection dropped? Your changes queue locally and replay the moment you are back.

Reload-proof

The queue survives closing the tab. Nothing you did is lost while you are away.

Real People. Real Websites Built with AI.

"I built my entire portfolio site in 20 minutes. My clients think I hired a designer. Already got 3 new inquiries this month."
Marcus T. · Freelance Graphic Designer, Austin TX
"We switched from Wix to Playcode. The AI actually understands what we need instead of giving us cookie-cutter templates. Saved us thousands."
Sarah Chen · Owner, Bloom & Petal Floristry
"I update my property listings from my phone while showing apartments. Clients are impressed when I tell them I built the site myself."
David Morales · Real Estate Agent, Miami FL

Simple Pricing

Start small. Upgrade when you're ready.

Starter

$0to start

Try the AI website builder and see results

  • AI credits included to start
  • Publish your site instantly
  • Subdomain included
  • Website hosting included
  • No credit card required
Get Started

Pro

Most Popular
$25/month

Everything you need to build

  • 100 AI credits/month
  • All AI models (12+)
  • Visual editing
  • Custom domains
  • Website hosting included
  • Export your code anytime
  • Private projects
  • Unlimited collaborators
Start Building

Cancel anytime. No hidden fees.

How credits work

Credits are used when AI helps you. Simple edits cost less, complex features cost more.

  • "Change button color" ~0.3-0.5 credits
  • "Add a contact page" ~2-3 credits
  • "Build full landing page" ~5-10 credits

Most users never run out. 100 credits = lots of building.

Questions to Ask Before Building Inventory Management Software

Yes. Describe the SKUs, locations, stock events, roles, screens, imports, reports, and recovery rules you need. Playcode can build the interface, server logic, database-backed ledger, and tests. Your team still owns the stock model, acceptance criteria, access review, physical-count process, and published operation.

No. Playcode is an AI app builder that can create a bounded custom inventory workflow as real code. This page does not claim a packaged ERP or WMS, ecommerce fulfillment, purchasing suite, shipping system, native barcode scanner, label provider, device support, or forecasting product.

Give every SKU, location, transaction, request, actor, import batch, balance, reconciliation, and audit event a stable identity. Keep receipt, issue, transfer, and adjustment entries durable. Materialize the current balance for fast reads, then reconcile it against the transaction ledger rather than trusting an editable total.

An exact retry is the same logical request after a double-click or lost response. Reuse its request ID and fingerprint, then return the original result. Concurrent issues are different requests competing for stock. Protect them with a transactional condition, record version, or row lock so the quantity cannot fall below zero.

Yes, when the import has stable source-row identity, field mapping, full-batch validation, duplicate rules, row-level outcomes, authorization, and reconciliation. Define export roles and fields separately. Start with fictional or redacted data, and do not treat code export as proof that live inventory data exports automatically.

No. The artifact has no barcode, label, camera, scanner, mobile-permission, offline, or hardware-provider path. Those claims require a separate product prerequisite with real devices, formats, permissions, validation, retry behavior, provider setup, and transaction-integrity tests. A generated illustration cannot provide that proof.

Not by default. This page proves no forecasting, reorder optimization, demand model, anomaly label, or business outcome. Add a planning model only after defining source records, time windows, late and corrected data, calculation versions, evaluation, decision ownership, and a safe way to keep suggestions separate from authoritative stock.

Recalculate expected SKU/location balances from durable transaction entries. If a recovered materialized balance differs, lock new writes, diagnose the bounded cause, repair only from reviewed entries at the expected version, and reconcile before unlocking. A whole-app restore returns code, files, and database to a saved point, including its inventory timeline.

Still have questions? Contact us

Choose the right Playcode path

All Playcode builders Compare app, website, bot, and business-workflow paths.Internal tools Explore the broader capability for operational databases, dashboards, approvals, and protected team workflows.How to create an inventory management system Follow the ledger, authorization, retry, concurrency, import, reconciliation, and recovery procedure before expanding the build.AI dashboard builder Build defined, access-controlled metrics and reconciliation views over owned operational records.AI form builder Build validated intake and update forms around owned records, roles, and submission rules.

Build the stock ledger around one workflow your team can verify.

Describe the SKUs, locations, movements, roles, and count rules. Test the complete transaction and recovery loop before adding scope.

An inventory ledger for two storerooms with receipts, issues, transfers, and manager adjustments...Build My Inventory App

No credit card required. AI credits included.