Executive summary
- What: The PointOfSaleDevice object in the GraphQL Admin API gains a nullable fiscalDeviceIdentifier field on version 2026-10, returning the Shopify-assigned fiscal register identifier for a POS device.
- Why: Countries that require cash registers to be registered with the tax authority can now read that identifier through the API instead of tracking it in a spreadsheet alongside Shopify.
- Who: Retailers trading in fiscally regulated markets, Sweden first, and the apps that handle fiscal transaction signing or journal reporting on their behalf.
What changed
Query fiscalDeviceIdentifier on PointOfSaleDevice and you get back the fiscal register identifier that Shopify has assigned to that device. In Sweden this is the manufacturing number, the tillverkningsnummer, that merchants register with Skatteverket. The field is nullable by design: it returns a value only for devices at locations in countries whose fiscal regulations require a registered cash register, and null everywhere else. Sweden is the first supported country.
Reading the field needs one of the existing order or device scopes, including read_point_of_sale_devices. Shopify treats the value as stable for the lifetime of the device registration, which means it is safe to cache per device rather than re-querying on every transaction. Inside a POS UI extension, session.deviceId is available in POS UI Extensions API 2026-04 and later, and you can pass that identifier into an Admin API query.
Why it matters
Fiscal compliance is one of the few areas of retail operations where a record keeping gap becomes a legal exposure rather than an inconvenience. In regulated markets each till must be registered, and every signed transaction or journal export has to be attributable to a specific registered register. Until now the mapping between a Shopify POS device and its registered fiscal identifier lived outside the platform, usually in a spreadsheet maintained by whoever set up the hardware.
That arrangement fails in predictable ways. Devices get replaced after damage, stores relocate, and staff swap hardware between locations during busy periods. Each event silently invalidates the mapping, and the discrepancy usually surfaces during an audit rather than during normal operations. Pulling the identifier from the same API that reports the transactions makes the link authoritative instead of maintained by hand.
Retailers reviewing their in-person setup should treat this alongside the rest of their Shopify POS configuration rather than as an isolated API detail.
Role-specific impact
- Marketers: No practical impact. This is a compliance and reporting field with no customer-facing surface.
- Developers: A single nullable field to add to existing PointOfSaleDevice queries. Handle null as the normal case, since most devices worldwide will return nothing.
- Store admins: Device to register mapping becomes something the system reports rather than something staff maintain, which removes a recurring source of audit findings.
Use-case example
Real-world scenario
A Swedish home goods retailer operates 18 stores on Shopify POS and exports signed fiscal journals monthly for Skatteverket. Register identifiers were held in a shared spreadsheet, so each monthly export began with an analyst reconciling device serial numbers against registered manufacturing numbers, roughly six hours of work. Two hardware swaps during the previous year went unrecorded, and the resulting mismatches took several weeks to untangle with the tax agency. After adopting fiscalDeviceIdentifier, the export tool reads the identifier directly per device, reconciliation dropped to under 30 minutes a month, and mismatches caused by unrecorded hardware changes went to zero.
Implementation checklist
- Confirm whether any of your locations sit in a country with registered cash register requirements. If not, no action is needed.
- Move the relevant integration to GraphQL Admin API version 2026-10.
- Add fiscalDeviceIdentifier to your existing PointOfSaleDevice queries and verify your app holds a sufficient scope, such as read_point_of_sale_devices.
- Handle a null return as the expected case for devices outside regulated markets, not as an error condition.
- In POS UI extensions, read session.deviceId on POS UI Extensions API 2026-04 or later and query the Admin API with that identifier.
- Cache the value per device and refresh it when device registration changes rather than on every transaction.
- Replace manual device to register mappings in your journal export process and reconcile once against the old spreadsheet before retiring it.
FAQ
Q: Our stores are all in North America. Do we need to do anything?
A: No. The field returns null for devices at locations without registered cash register requirements, and no part of your POS setup changes.
Q: Will more countries be added?
A: Sweden is the first supported country and the field is structured to cover others as support arrives. Build your handling around the field being present but null rather than around Sweden specifically.
Resources
PointOfSaleDevice object reference
Need guidance? Talk to Makro.