# Billing & subscription Source: https://docs.pxaccounting.com/account/billing Add a payment method, replace one, or remove the card or bank account on file. PX uses Stripe for billing. Adding a payment method opens Stripe Checkout in a new tab; PX never sees raw card or bank details. ## Adding a payment method 1. Open **Settings**. 2. Find the **Billing & Subscription** card. 3. Click **Add Payment Method**. A new tab opens with Stripe Checkout. Pick the payment type (card or US bank account) and enter the details: * **Card** - card number, expiry, CVC. PX accepts Visa, Mastercard, Amex, Discover. * **Bank account** - routing number, account number. ACH transactions take 3-5 business days to clear. After Stripe confirms the payment method, you are returned to PX. The Billing card now displays the saved method. Billing card ## Replacing a payment method To swap one card for another: 1. Click **Remove** on the current method. 2. Click **Add Payment Method**. 3. Enter the new details in Stripe Checkout. There is no direct "edit" path - removing and re-adding is the supported flow. This keeps tokenization clean and avoids stale tokens at Stripe. ## Removing a payment method Click **Remove** on the Billing card. PX: * Detaches the payment method from your Stripe customer record. * Updates the card to show *No payment method*. After removal, future invoices will fail to charge until you add a new method. PX will send reminder emails. ## What gets charged PX bills monthly based on: * Your subscription plan. * (For metered plans) the number of properties under management during the month. Invoices are generated at the start of each billing cycle and charged automatically against the saved payment method. You can view invoices and receipts in your Stripe customer portal (link sent via email after payment). ## Failed payments When a charge fails: * PX retries automatically per Stripe's smart retry logic. * You receive an email with the failure reason and a link to update your payment method. * Repeated failures eventually pause the account - you will not be locked out, but new audits may be disabled until billing is current. ## Receipts Stripe emails receipts after every successful charge. To resend a receipt: 1. Open Stripe's billing portal (link in any prior receipt email). 2. Find the invoice. 3. Click **Email receipt**. You can also view all invoices and download PDFs from the portal. # Delete your account Source: https://docs.pxaccounting.com/account/delete-account What happens when you delete a PX Accounting account. Account deletion is permanent and cannot be reversed. Read this page before clicking the button. ## Where it lives **Settings** -> scroll to the **Danger Zone** section -> **Delete Account** button. Clicking the button opens a confirmation dialog with a 2FA-style verification step. You must complete the verification to proceed. ## What gets deleted When you confirm: * **PMS credentials** - encrypted credentials and OAuth tokens are removed, whichever connection type you used. * **Webhook subscriptions** - PX unregisters its webhook endpoints with your PMS. * **Properties** - synced and manual properties. * **Reservations cache** - any cached reservation data. * **Business models** - all models and their version history. * **Tax configuration** - including channel sync overrides and Airbnb remittance. * **OwnerRez catalog** - all rows. * **Audit history** - every audit you have run. * **Issue history** - findings, fix actions, dismissals. * **Billing record** - the Stripe customer record is deleted; saved payment methods are detached. * **Authentication** - your Clerk identity is removed; you are logged out and cannot log back in to this account. ## What stays A few things survive deletion: * **Anonymized usage logs** - retained per the privacy policy for security and abuse prevention. * **Stripe transaction history** - tax authorities require us to keep payment records. * **Audit log of the deletion itself** - for compliance. None of these contain personally identifiable information beyond what tax law requires. ## What does NOT get deleted * **Your PMS data** - PX is read-only against your PMS. Nothing in your PMS is changed by deleting your PX account. * **PMS webhook history** - your PMS may keep a record of webhooks it sent before PX was disconnected. That is on the PMS side. * **Bookings, owners, listings in your PMS** - all preserved. ## Before deleting Consider: * **Export anything you want to keep.** Audit PDFs - download them first. Once the account is deleted, they are gone. * **Cancel billing first** - or it can be done as part of deletion, but doing it explicitly via Stripe ensures no last-minute charges. * **Check for in-flight audits** - cancel any running audits before deleting; otherwise the worker may emit errors. * **Inform team members** - if multiple people use the account, deletion affects them all. ## Alternative: disconnect without deleting If you are unsure, disconnect the PMS instead of deleting the account: * Open **Settings**. * In the PMS card, click **Delete** (Guesty) or **Disconnect** (OwnerRez). This removes your credentials, webhooks, and synced properties, but preserves your business models, audit history, and other account-level configuration. You can reconnect anytime. This is the right choice if: * You are switching from one PMS to another and want to keep history. * You are pausing operations and may resume later. * You want to stop syncs while preserving the option to come back. Account deletion is for when you are sure you do not want PX at all. ## Reactivation Account deletion is final. There is no "undo" window. Re-creating an account with the same email starts from a fresh slate - no business models, no audit history, no integrations. If you delete by mistake, contact [support@pxaccounting.com](mailto:support@pxaccounting.com) immediately. There is a small grace window (typically 7 days) during which we may be able to recover, but no guarantees. # Account settings Source: https://docs.pxaccounting.com/account/settings Guesty credentials, integration status, account preferences, billing, and danger zone. The **Settings** page is the home for everything that affects your account globally - your PMS connection, integration health, your timezone, billing, and (when needed) deleting the account. The page is organized into cards: 1. **Guesty API Credentials** 2. **Integration Status** 3. **Account Preferences** 4. **Billing & Payment** 5. **Danger Zone** ## Guesty API Credentials This card shows how your Guesty account is connected and lets you remove the connection. A **Connected via Guesty Marketplace** badge sits next to the card title, and the subtitle reads *Your Guesty account is connected and syncing properties*. Guesty issued the credentials when you connected, so there is nothing to paste or edit here. See [Connect Guesty](/integrations/connect-guesty) for how the connection is made. If your badge reads **Connected with API keys** instead, your account is on an older connection type that PX no longer sets up. It keeps working, and nothing here needs your attention. Contact [support](mailto:support@pxaccounting.com) before you disconnect it, because reconnecting will move you to the Marketplace flow above. This card is provider-specific. On an OwnerRez account it reads **OwnerRez Connected** instead, with the subtitle *Your OwnerRez account is connected via OAuth* (or *via Personal Access Token*) and a **Disconnect** button. Before any PMS is connected, the card is **Connect Your PMS** and shows the provider picker. Guesty connected ### What the card shows * **Guesty Account ID** - a read-only identifier for your Guesty account. Quote this ID when you contact Guesty support. Your Guesty account name appears just below the field. * **Connected** - the date the connection was last established. If the Account ID field is empty and reads *Not read from Guesty yet. It appears after the next sync*, the connection predates this field. It fills in automatically after the next daily sync. To reconnect, disconnect PX Accounting on its [partner page in Guesty](https://app.guesty.com/integrations/partners/pxaccounting) and connect again. The connection is not editable from inside PX: Guesty issues the credentials in exchange for a one-time key and does not make them retrievable afterwards, so there is nothing here to change. ### Deleting the connection Click **Delete** to remove the connection. PX asks you to confirm, then: * Removes the stored credentials. * Unregisters the webhook. * **Removes all synced properties.** Deleting Guesty credentials also deletes your synced properties. This cannot be undone. You can only have **one** active PMS at a time. Switching providers means deleting the existing connection first. ## Integration Status This card reports the health of your PMS integration and lets you retry anything that failed. It shows up to two rows, depending on your provider and connection state. **Admin Account** (Guesty only, and only when PX manages one) - reads *Created: ``* with a green check, or *Not created yet* with a red X and a **Retry** button. **Webhooks** - always shown. The summary line tells you exactly where you stand: | Summary | Meaning | Retry available | | --------------------------------------------------- | -------------------------------------------------------------- | --------------- | | *Registered and active* | Healthy. Changes in your PMS reach PX as they happen. | - | | *Registered to an old address - re-register to fix* | The webhook points at a stale URL. | Yes | | *Partially registered (n/m)* | Only some webhook events registered. | Yes | | *Not registered* | No webhook is registered. | Yes | | *Not configured on server* | Marked N/A. Nothing to do on your side. | No | | *Not available (requires OAuth)* | Marked N/A. Your connection type does not support webhooks. | No | | *Status unknown* | PX could not determine the state. The error follows the label. | Yes | Each failed row has its own **Retry** button - there is no page-wide refresh. The most common failure is a Guesty plan limit on the number of webhooks. Remove an unused webhook in Guesty, then click **Retry**. Integration status ## Account Preferences A single setting: * **Timezone** - Eastern (ET), Central (CT), Mountain (MT), Arizona (MST), Pacific (PT), Alaska (AKT), or Hawaii (HST). New accounts default to Central. All date calculations for diagnostics and issue detection use this timezone. See [Timezone](/account/timezone) for what the setting affects and what it does not. ## Billing & Payment Manage the payment method used for monthly subscription billing: * **No payment method** - shows an **Add Payment Method** button that opens Stripe Checkout in a new tab. * **Card on file** - shows the brand and last 4 (for example, *Visa ending in 4242*) plus expiration, with a **Remove** button. * **Bank account on file** - shows the bank name and last 4, with a **Remove** button. See [Billing](/account/billing) for the full billing workflow. ## Danger Zone A single button: **Delete Account**, described as *Permanently delete your account and all associated data*. Clicking it opens a confirmation dialog with a verification step. Deleting: * Removes your PMS credentials. * Removes business models, tax configuration, and audit history. * Cancels billing. * Logs you out. Irreversible. See [Delete account](/account/delete-account). ## Layout notes Settings is the **first stop** for new users. PX sends new sign-ins here when no PMS is configured, because nothing else works without a PMS connection. Existing users typically only return to Settings to: * Check integration status after a change on the PMS side. * Update the timezone after moving offices. * Replace a payment method. * Disconnect when offboarding. # Timezone Source: https://docs.pxaccounting.com/account/timezone What the account timezone affects and what stays in PMS time. PX stores the underlying timestamps for every reservation in UTC. The **timezone** setting on the Account Preferences card controls how those timestamps display in the UI. ## How to set it 1. Open **Settings**. 2. In the **Account Preferences** card, open the **Timezone** dropdown. 3. Pick from the US timezone list: * Pacific (US/Pacific) * Mountain (US/Mountain) * Central (US/Central) * Eastern (US/Eastern) * Alaska (US/Alaska) * Hawaii (US/Hawaii) 4. PX shows a *"Timezone updated successfully"* toast. Saving is automatic. There is no Save button. ## What the timezone affects | Surface | Affected | | ----------------------------------------------------- | -------- | | Property detail - reservation arrival/departure dates | Yes | | Audit results - arrival/departure | Yes | | Findings - detected/fixed timestamps | Yes | | Home dashboard - trend chart | Yes | | Issue detected/fixed dates | Yes | ## What it does not affect | Surface | Reason | | --------------------------------- | -------------------------------------------------------------- | | Stored timestamps in the database | Always UTC. Timezone is display-only. | | The PMS itself | PX is read-only against your PMS. | | Business model activation date | Stored as a date, not a timestamp - timezone-agnostic. | | Audit date range pickers | The pickers select calendar dates regardless of timezone. | | Audit PDF exports | Exports use the user's display timezone at the time of export. | ## Why only US timezones? The current dropdown is constrained to US timezones because PX's customer base is US-centric. Reach out to [support@pxaccounting.com](mailto:support@pxaccounting.com) if you need a non-US timezone. ## Edge cases * **Daylight saving time** - PX handles DST automatically. The timezone you pick is the IANA zone (US/Pacific, etc.), not a fixed offset. * **Properties in a different timezone from your account** - timezones are account-level today, not per-property. Bookings still display in your account timezone, even when the property is elsewhere. PMS-reported check-in/check-out times are unaffected. * **Multi-user accounts** - the timezone setting is per-account, not per-user. If multiple people work in your account from different cities, they all see the same display timezone. # Accounting Audit Source: https://docs.pxaccounting.com/audit/accounting-audit Ledger and guest-money integrity checks, and how to work through the issues they raise. The **Accounting Audit** checks that money and books line up: that guest payments landed, that ledger entries balance, that cancellations did not leave funds stranded, and that postings fall in the period they belong to. It is the counterpart to the [Financial Audit](/audit/run-an-audit), which checks whether the right *amounts* were charged. The Financial Audit asks "is this booking priced and taxed correctly?" The Accounting Audit asks "did the money and the bookkeeping end up where they should?" PX does not keep a ledger of its own. It reads the ledger your PMS produces and audits it. Where a check needs to know what a posting *should* have been, PX computes that expectation internally for the comparison only. ## Where it runs The Accounting Audit runs as part of [Month-End Close](/audit/month-end-close). Pick a month, click **Generate**, and PX runs it alongside the Financial Audit. Results land in the **Accounting Audit** tab, with the issue count in the tab label. You do not have to wait until the month is over. Month-End Close runs on demand, any day of the month, for any month you pick, so you can check an in-progress month as often as you like. Issues also appear per property, on the **Overview** tab of any [property detail](/properties/property-detail) page, so you can work a single listing without opening a close. ## What it needs Two things affect how much the Accounting Audit can check: **The Guesty Accounting Add-on.** Ledger checks read journal entries. If Guesty reports no Accounting Add-on for your account, those checks cannot run and the close tells you so. Results are then **incomplete, not clean**, and re-running will not change that - the add-on has to be enabled in Guesty. **Business models.** Revenue-recognition and fee-allocation checks compare postings against the model assigned to the property. Without an assigned, active [business model](/business-models/overview), those checks stay off. The Accounting Audit tab links you to Business Models when none are configured. ## What it checks The exact mix depends on your PMS and on what your accounting data exposes. At a high level: **Guest money** - payments that were never recorded, payments larger than the balance due, cash collected that does not match the total paid, and funds held beyond what the booking justifies. **Ledger integrity** - entries that do not balance, expected entries that are missing entirely, and postings dated outside the period they belong to. **Cancellations** - canceled bookings that left a non-zero owner balance, held funds that were never released, and revenue that stayed uncollected. **Business-model conformance** - commission that is missing, short, or at the wrong rate; fees allocated to the wrong party; and amounts routed somewhere the model does not call for. See [What an audit checks](/audit/check-categories) for how these group into check classes by PMS. ## Severity Every issue carries a severity, and the close summarizes them as tiles: | Severity | Treat it as | | ---------- | ------------------------------------------------------- | | **High** | Money is probably in the wrong place. Work these first. | | **Medium** | Worth resolving before you close the period. | | **Low** | Informational. Clear when convenient. | ## Working through issues Accounting Audit issues Four cards sit above the list. Two of them are scoped to the month you are closing, and two are not: | Card | Scope | | --------------------------- | --------------------------------------------------------------------------- | | **Unresolved** | This close. Carries a **Needs Review** badge while the count is above zero. | | **Fix in Progress** | This close. | | **Total Issues (All Time)** | Every issue on the account, not just this month. | | **Fixed (All Time)** | Every issue ever resolved on the account. | Keep that difference in mind when the numbers do not appear to add up: the two all-time cards are a running total, not a monthly figure. ### Narrowing the list Three dropdowns filter what you see: * **Status** - **Open only**, **All statuses**, **Unresolved**, **Fix in progress**, **Fixed**, or **Dismissed**. * **Severity** - **All Severities**, or one of high, medium, low. * **Issue type** - **All Issue Types**, or a single check, such as *Canceled: Uncollected Revenue*. ### The lifecycle Each issue moves through a short lifecycle: | Status | Meaning | | ------------------- | ---------------------------------------------------------- | | **Unresolved** | New, untouched. | | **Fix in progress** | You have started on it. PX records when. | | **Fixed** | Resolved. | | **Dismissed** | Closed without fixing - a false positive, or out of scope. | **Unresolved** and **Fix in progress** together are what PX calls *open*. Where you opened the list changes what you see first. In Month-End Close it starts on **Open only**, so marking an issue fixed clears it out of the working list. On a property page the panel is titled **Accounting Audit Log** and starts on **All statuses**, because there it doubles as the history for that listing. Resolved issues are never deleted in either place - they move out of the way, and the status filter brings them back. ### Acting on issues Every issue row carries **Mark Fixed**, **Start Fix**, and **Dismiss** buttons. A bar above the list applies the same actions in bulk, and it adds **Reopen** for putting resolved issues back. It reads *`` issues shown - Apply to all shown*, and that wording is exact: bulk actions hit every issue currently passing your filters, not a set you tick individually. Bulk actions apply to everything the filters are showing. Narrow the list first - by severity, issue type, or status - and check the count in the bar before you click. To reopen a batch, filter to **Fixed** or **Dismissed**, confirm the count, then click **Reopen**. Marking an issue fixed or dismissed removes it from the exception counts and the money flagged for that close. The headline banner and the Overview figures move as you work, so resolve issues because they are genuinely resolved, not to clear the number. ### What a row tells you Each issue shows, in order: a **severity** badge, a **status** badge, the **check name** (for example *Canceled: Uncollected Revenue*), and the **listing** it belongs to. Beneath that: * A plain-English explanation of what went wrong and what to do about it, usually ending in a numeric breakdown so you can see how PX arrived at the figure. * **Open in Guesty** - jumps straight to the reservation in your PMS. * **Why this was flagged** - expands to show the rule PX applied, why this particular booking tripped it, and what to check. * **Detected** - the date PX first raised the issue. ## Letting PX close them for you With [auto-fix](/properties/auto-fix) on for a property, PX moves unresolved issues into a queue and works them in the background. The per-issue **Start Fix** and **Dismiss** buttons are replaced by a **Fix in Progress** badge, and PX updates the status once the change is confirmed with your PMS. Leave auto-fix off while you are onboarding, or when you want a human on every issue the first time around. ## Timing versus collection gaps Some money the Accounting Audit flags is not money you failed to collect - it is money booked into the wrong period. Month-End Close reports this separately, as a note under the Accounting Audit money box reading *booked in the wrong period (timing, not a collection gap)*. Read it that way when you reconcile: a timing figure means the period boundary is wrong, not that cash is missing. ## What's next Run both audits over a month and review them together. How to read an individual finding. # What an audit checks Source: https://docs.pxaccounting.com/audit/check-categories The three classes of checks PX runs against your reservations. The [Accounting Audit](/audit/accounting-audit) groups its checks into three classes. The exact mix depends on your PMS - some checks rely on accounting data only certain PMSes expose - but a run covers all three categories at a high level. ## Class 1 - cross-system validation When your PMS has a built-in accounting engine, PX cross-checks its postings against your business model. This catches discrepancies between what the PMS recorded and what your management agreement says should have happened. Class 1 is available where the PMS exposes a usable accounting feed. Where it is not, PX falls back to Class 2 and Class 3, which together cover the same ground using a different approach. ## Class 2 - data consistency PX validates that the numbers your PMS reports reconcile against themselves and against your tax and commission configuration. Examples of what this catches: * Taxes that should have been collected but were not. * Fees and commissions whose amounts do not match the configuration. * Bookings with payment anomalies (missing, duplicated, or unbalanced). * Bookings whose totals do not match the sum of their charges. * Calendar overlaps and bookings that look stale. Class 2 runs on every PMS PX supports. ## Class 3 - business model validation PX takes the per-charge data your PMS provides and checks it against the **business model** you have assigned. This is where ledger balance and owner statement reconciliation findings come from. Class 3 only runs for properties that have an assigned, active business model. Class 3 covers questions like: * Does the owner payout we calculated match the payout the PMS recorded? * Are charges recognized on the dates the business model says they should be? * Does the commission rate applied match the rate in the model? ## What does *not* get checked PX is an accounting and trust audit tool. It does not check pricing decisions, channel performance, forecasting, marketing, or guest communication. Pricing and revenue management belong elsewhere. ## Severity and verdicts The two audits score their results on different scales: * **Accounting Audit** issues are **high**, **medium**, or **low**, and you close each one out as fixed or dismissed. See [Accounting Audit](/audit/accounting-audit). * **Financial Audit** findings carry a severity of `error`, `warning`, or `info`, and contribute to an overall verdict of `CLEAN`, `UNDERPAID`, or `OVERPAID`. See [Understanding findings](/audit/understanding-findings). ## In-product reference The in-app results show the specific check name, expected amount, actual amount, and reasoning for every finding. That is the canonical reference for what a given finding means and how to triage it. # Export an audit as PDF Source: https://docs.pxaccounting.com/audit/export-pdf Generate a shareable PDF report from any audit. Every completed audit can be exported as a PDF. The button is at the top of the results table. Audit results with Download Report ## Generating 1. Run an audit (see [Run an audit](/audit/run-an-audit)). 2. Once results load, click **Download Report**. 3. PX builds the PDF in the browser and downloads it. The PDF includes: * **Cover page** - audit ID, date range, listing filter, generated-at timestamp, your account name. * **Summary** - reservations audited, issues found, verdict, total under-collected, total over-collected. * **Findings breakdown** - count by finding type. * **Per-reservation results** - one row per reservation, with line items and findings underneath. * **Configuration snapshot** - relevant tax configuration, business model, and (if Airbnb) remittance settings at the time of the audit. This is useful for reproducibility - reviewers can see what rules drove the findings. ## Sharing Three common patterns: * **Email to an owner** with their property's findings, after running an audit with the listing filter set to that property. * **Attach to an accountant email** as part of period close. * **File internally** with the period's accounting documents for trust-account compliance. There is no per-recipient access control on the PDF - anyone you send it to can read it. Use account-level access controls in your email platform if confidentiality matters. ## What is included from configuration The PDF embeds a configuration snapshot taken at audit time. This is sourced from: * **Tax Configuration** - account-level taxes and the Airbnb remittance settings. * **Business Model** - the model assigned to each property at the audit's date range. * **PMS settings** - the active PMS and integration status (provider, account, last refresh). This snapshot reflects the configuration *at the time of audit generation*, not at the time of viewing. Re-running an audit with updated configuration produces a fresh PDF. ## File naming PX auto-names the file as: ``` px-audit----.pdf ``` For example: `px-audit-2026-04-01-2026-04-30-all-20260504.pdf`. Rename it however you like after download. ## Limitations * PDFs are generated in the browser. Very large audits (5,000+ reservations) may take 30-60 seconds to render and may stutter on older machines. If you need a smaller file, run audits with a tighter listing filter. * Images and brand customization are not yet supported - PDFs use the default PX style. * Custom watermarks (DRAFT, FINAL) are not yet a feature. Add them with a PDF tool after download if needed. # Month-end close Source: https://docs.pxaccounting.com/audit/month-end-close Run the audit and diagnostics for one month and review the combined result in a single place. **Month-End Close** runs both of PX's audits over a single month and puts the combined result on one page: the [Financial Audit](/audit/run-an-audit) (fees, taxes, and commission) and the [Accounting Audit](/audit/accounting-audit) (ledger and guest-money integrity). Use it as the monthly ritual you hand to your accountant. Despite the name, you can run a close at any time of the month, as often as you like. It runs on demand for whichever month you pick, so you can check an in-progress month mid-month, re-run after fixing something, or close a month from last quarter. Nothing about it is tied to the calendar rolling over. Open **Month-End Close** in the sidebar. Month-End Close Month-End Close is on for all accounts by default. If the sidebar entry is missing, it has been disabled for your user - contact support. PX sends you back to Home if you open the page directly while it is disabled. ## Running a close The controls sit in a card at the top of the page: * **Month** - the month to close. * **Listing** - a single property, or **All Listings** (the default). * **Generate** - starts the run. The button reads *Running...* while it works. If you have not run anything yet, the page reads *Pick a month and click Generate to run the close*. A run moves through three phases, with elapsed seconds beneath: *Starting audit and diagnostics*, *Running audit and diagnostics for the month*, then *Combining results*. You can leave the page open while it works. Once a result is on screen, a hint tells you what you are looking at: *Showing ``. Change the month and click Generate to re-run.* ### Download PDF **Download PDF** appears next to **Generate** after a run completes. The PDF is scoped to the month and the listing you selected, so a single-listing close exports that listing only. ## Reading the result A banner at the top gives you the headline: | Banner | Meaning | | --------------------------------------------------- | ------------------------------------------------------------------------ | | Green - *Books balance for ``* | No exceptions. Nothing to resolve. | | Amber - *`` exceptions to resolve for ``* | The subtitle gives the money flagged and how many bookings were audited. | | Red - *Close could not be completed for ``* | The run failed. PX shows the reason. | When a close fails, PX suppresses the numbers below the banner rather than showing zeros - an empty *0 flagged / CLEAN* body under a red banner would read as a clean month. If Guesty rate-limited the request, wait a few minutes and click **Generate** again. Guesty applies both a per-minute throttle and a daily authorization cap, and the daily cap clears in hours rather than minutes, so the message tells you which one you hit. ### Warnings that qualify a result These appear above the tabs and mean the numbers are incomplete rather than clean: **Some listings could not be audited** - the close is partial and may understate leakage. **Ledger checks did not run** - Guesty reports no Accounting Add-on for the account, so journal entries could not be read. Re-running will not help; the add-on has to be enabled in Guesty. **Ledger checks were skipped for some reservations** - a journal-entry fetch failed. Re-run to complete them. **The audit window could not be trimmed to this month** - the audit and diagnostics may cover different date ranges. **Config sync incomplete for this close** - the point-in-time rate history did not fully reconcile, so a recent fee, tax, or markup change may not be reflected. Re-run the close; if it recurs, check the configuration sync. ## Overview tab Three money boxes split the exposure, and the total is exactly the other two added together: * **Total money flagged** - Financial + Accounting combined. * **Financial Audit** - fees, taxes and commission. * **Accounting Audit** - ledger and guest-money integrity. Each box separates **under-collected** from **over-collected**. The Accounting box may add a note that money was *booked in the wrong period (timing, not a collection gap)* - that figure is a period problem, not money you failed to collect, so it sits outside the under/over split. Below the boxes, seven tiles summarize the month: | Tile | What it tells you | | -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Audit verdict** | The Financial Audit's overall call, in caps - `CLEAN` when nothing is flagged, otherwise the dominant problem (for example `UNDERPAID`). | | **Bookings audited** | How many bookings PX checked, and how many had issues. | | **Accounting Audit issues** | Issue count, with the high-severity count beneath. | | **Listings tied out** | How many listings reconciled, out of the total. | | **High / Medium / Low severity** | Exception counts by severity. | ## Financial Audit tab The full Financial Audit results table for the month, identical to the one on the **Financial Audit** page - see [Audits overview](/audit/overview) for how to read it. Column preferences here are stored separately, so you can lay the two tables out differently. ## Accounting Audit tab Reservation and folio integrity issues for the month. Four cards sit above the list: **Unresolved** and **Fix in Progress** for this close, plus **Total Issues (All Time)** and **Fixed (All Time)**, which are running account totals rather than monthly figures. The list itself defaults to **Open only** so it shows outstanding work. You can mark issues fixed, start a fix, dismiss, or reopen them from this tab, one at a time or in bulk. Resolving an issue removes it from the exception counts and the money flagged for this close, so the headline banner and the Overview figures update as you work. See [Accounting Audit](/audit/accounting-audit) for the filters, the bulk actions, and how to read an individual issue. If you have no business models configured, this tab prompts you to set them up. Revenue-recognition and fee-allocation checks cannot run without them. See [Business models](/business-models/overview). ## Listings tab A sortable per-listing breakdown, so you can see which properties account for the month's exposure. Month-End Close listings Filter with **All**, **With issues**, or **Tied out only**. The count of visible rows sits beside the filters, so on a large portfolio you can tell at a glance how much the filter removed. | Column | What it shows | | ------------------ | --------------------------------------------------------------------- | | **Listing** | Property name. | | **Money flagged** | Combined financial and accounting exposure for that listing. | | **Audit findings** | Financial Audit findings. | | **Diagnostics** | Accounting Audit issues. | | **Status** | **Tied out** when the listing reconciled, **Review** when it did not. | Click any column header to sort. The table opens sorted by **Money flagged**, descending, which puts your largest problems first. A listing can show **Review** with zero Audit findings: one Accounting Audit issue is enough to hold it open. Check the **Diagnostics** column before assuming a clean Financial Audit means a clean listing. ## Analytics tab Five charts over the same month. Month-End Close analytics * **Exceptions by severity** - combined Financial and Accounting exceptions, split high / medium / low. These are the same counts as the severity tiles on the Overview tab. * **Money flagged by listing** - your most exposed listings, ranked by combined financial and accounting exposure. Useful for deciding which property to work first. Month-End Close analytics by type * **Exceptions by type** - findings by category across both audits, so you can see whether the month is dominated by one recurring problem. Categories are the human-readable check names, such as *Missing Fee*, *Fee Amount Mismatch*, *Missing Payment*, *Tax Amount Mismatch*, *Ad Ledger Balance Mismatch*, or *Canceled Uncollected Revenue*. * **Money flagged by type** - the same categories ranked by dollars rather than count. The two often disagree: the most frequent exception is rarely the most expensive one, so read them together before deciding where to spend time. * **Revenue composition** - what guests were charged, from Financial Audit line items, broken into **Rent**, **Expense**, **Tax**, and **Fee**. Expenses plot to the left of zero because they reduce what reaches the owner, so the axis runs negative as well as positive. Each chart shows an empty message instead of an axis when the month has nothing to plot. ## What's next How to read an individual finding. What each class of check looks for. # Audits overview Source: https://docs.pxaccounting.com/audit/overview The two audits PX runs - the Financial Audit and the Accounting Audit - and when to use each. PX runs **two** audits. They answer different questions, produce different kinds of results, and you reach them in different places: | | Financial Audit | Accounting Audit | | ----------------------- | ---------------------------------------- | ------------------------------------------------------ | | **Question it answers** | Were the right amounts charged? | Did the money and the books end up in the right place? | | **Covers** | Fees, taxes, and commission | Ledger and guest-money integrity | | **Scope you choose** | A date range, up to 62 days | A calendar month | | **Result** | Findings per reservation, plus a verdict | Issues you work through and close out | | **Severity scale** | `error`, `warning`, `info` | High, medium, low | | **Where you run it** | **Financial Audit** in the sidebar | As part of **Month-End Close** | Neither audit modifies your PMS. Both are read-only: PX audits the data your PMS produces. Pick a date range, choose a listing, click Generate. Ledger and guest-money integrity, and how to clear issues. Run both audits over one month and review them together. Severity, expected vs actual, config source, reasoning. ## Which one do you want? Reach for the **Financial Audit** when you have a question about amounts on bookings: a tax that looks wrong, a commission that does not match the agreement, a specific booking you want to investigate. You control the exact window, so it is the right tool for a narrow look at recent history or a single property. Reach for the **Accounting Audit** when you are closing a period and need the books to hold up: payments that never landed, ledger entries that do not balance, cancellations that left money stranded. It is scoped to a month because that is the unit a close is measured in. Most operators end up using [Month-End Close](/audit/month-end-close), which runs both over the same month and shows the combined exposure in one place. You do not have to wait for month end to use it - it runs on demand, any day of the month, for any month you pick. ## When to run an audit * **Period close** - use [Month-End Close](/audit/month-end-close) for the month you are closing. It covers both audits at once. * **Owner statement prep** - run before sending statements to catch issues that affect payouts. * **After a configuration change** - changed a tax rate or commission percent? Run a Financial Audit over the affected period to verify the new rules are applied. * **Onboarding a new owner or property** - audit recent history to validate the new business model. * **Investigation** - when a specific booking looks wrong, run a Financial Audit over a narrow window with a listing filter. ## What the Financial Audit returns A successful run returns three layers: ### Summary * **Reservations Audited** - total bookings in scope. * **Issues Found** - reservations with at least one finding. * **Verdict** - one of `CLEAN`, `UNDERPAID`, `OVERPAID`. The verdict reflects the net financial direction. ### Per-reservation results A table with one row per reservation: * Confirmation code (linked to the PMS where applicable). * Listing, guest, channel, status. * Number of findings. * Net discrepancy (positive when you under-collected, negative when you over-collected). Click a row to expand it. The expansion shows the **line items** on the booking and the **findings**, each with severity, expected, actual, difference, source, and reasoning. ### Findings breakdown A grid of finding types with counts. Click a type to filter the results table. ## Constraints These apply to the Financial Audit. Month-End Close takes a month instead of a range, so it is not affected. * The audit window cannot exceed **62 days**. For longer ranges, run multiple audits back to back. * The Generate button is disabled when the range exceeds 62 days, the start date is after the end date, or you have not connected a PMS yet. ## How long does an audit take? It depends on how many reservations are in the window. As a rough guide, PX checks **about 80 reservations per minute**, so: * A small portfolio over a month: usually under a minute or two. * A large portfolio over the full 62-day window: a few minutes, sometimes up to ten on the busiest accounts. While a run is in progress, leave the tab open. You can keep working elsewhere on your computer; just don't close the browser or navigate this tab to another PX page. An elapsed-time card shows progress, and your results appear on the same page when it finishes. # Run a Financial Audit Source: https://docs.pxaccounting.com/audit/run-an-audit Step-by-step walkthrough of generating a Financial Audit and reading the results. This page covers the **Financial Audit**: the audit that checks whether the right amounts were charged on each booking, across fees, taxes, and commission. It is the audit behind the **Financial Audit** entry in the sidebar. For ledger and guest-money integrity, see the [Accounting Audit](/audit/accounting-audit) instead. To run both over the same month, use [Month-End Close](/audit/month-end-close). Open the **Financial Audit** page in the sidebar. Financial Audit controls ## Set the parameters Three controls at the top: * **Start Date** - calendar picker. * **End Date** - calendar picker. * **Listing** - dropdown of `All Listings` plus every property in your account. Validation messages appear below if something is wrong: * *"Date range exceeds 62 days"* - shorten the window. * *"Start date must be before end date."* - flip the dates. Click **Generate Audit** to start. ## Watch progress While the audit runs, a loading card appears with: * A spinning icon. * The elapsed time since the run started. * Status text: **Running Audit...** You can leave the page - the audit continues in the background and the results are persisted under an audit ID. Coming back to the Audits page picks up where you left off. ## Read the results Three components show up when the audit completes. ### Summary cards | Card | Meaning | | ------------------------ | -------------------------------------------------------------------------------------------------------------------- | | **Reservations Audited** | Total bookings checked. | | **Issues Found** | Reservations with at least one finding. | | **Verdict** | `All Clear`, `Under-collected with amount`, or `Over-collected with amount`. The amount is the net financial impact. | ### Results table Columns: | Column | Meaning | | ---------------- | -------------------------------------------------------- | | (expand arrow) | Click to expand the row and see line items and findings. | | Arrival | Check-in date. | | Departure | Check-out date. | | Reservation Code | Confirmation code, linked to the PMS where applicable. | | Listing | Property name. | | Guest | Guest name. | | Channel | Booking channel. | | Status | Confirmed, canceled, etc. | | Issues | Count of findings, or a green checkmark if clean. | | Discrepancy | Net dollar difference for the booking. | Above the table, three controls: * **Status filter** - dropdown of statuses present in the results. * **All / Issues / Clean** - quick filter to all rows, only rows with findings, or only clean rows. * **Expand all / Collapse all** - bulk expansion of every row. ### Findings breakdown A grid of finding types with count badges. Click any type to filter the results table to bookings with that finding. ## Drill into a reservation Click the expand arrow on any row to see: * **Line items** - the rent, fees, taxes, and expenses on the booking with amounts. * **Findings** - one row per finding, showing: * Severity badge (error / warning / info). * Type label. * Description. * Expected amount. * Actual amount. * Difference (signed). * Config source (which configuration drove the expectation). * Reasoning (the formula PX used). Use this view to understand exactly why a finding fired. Most disputes resolve as soon as you read the reasoning - either the booking is wrong, the configuration is wrong, or there is a one-off circumstance you can document. Expanded reservation ## Export the audit as a PDF Click **Download Report** above the results table to export the audit as a PDF. See [Export PDF](/audit/export-pdf) for what the PDF contains and how to share it. ## Re-running Audits do not auto-refresh. To re-run with the same parameters: 1. Set the date range and listing again. 2. Click **Generate Audit**. Each audit gets a fresh ID. There is no concept of "updating" a past audit - just generate a new one. ## Common patterns ### Period close audit For closing a period, prefer [Month-End Close](/audit/month-end-close) - it covers this audit and the Accounting Audit over the same month, and exports one PDF. Use the range-based run below when you want the Financial Audit on its own: * Start: 1st of last month. * End: last day of last month. * Listing: All Listings. Save the resulting PDF to your accounting folder. ### Single-property investigation When a specific property has unresolved findings on its detail page: * Listing: that property. * Range: a 7-day or 14-day window around the affected reservation. Narrow scope means faster results and easier reading. ### Pre-statement reconciliation Before sending owner statements: * Range: the statement period. * Listing: All Listings (or per-property if you statement individually). Resolve any UNDERPAID or OVERPAID findings before publishing the statement. ## Troubleshooting **The audit returns zero results.** Check the listing filter - if you picked a property with no reservations in the window, results will be empty. Also verify the PMS is still connected (Integration Status under Settings). **The audit fails with an error.** The most common cause is a transient PMS rate limit. Wait a minute and try again. If the failure persists, check Integration Status; expired credentials produce repeatable failures. # Understanding findings Source: https://docs.pxaccounting.com/audit/understanding-findings How to read severity, expected vs actual, config source, and reasoning. Every finding in an audit answers four questions: 1. **What went wrong?** - the finding name and short description. 2. **How serious is it?** - the severity. 3. **What was expected?** - PX's calculated value, with the source. 4. **Why did PX expect that?** - the reasoning string. Once you internalize these four, you can triage findings quickly. Expanded finding ## Severity Three levels: * **Error** - a real discrepancy with a definite financial impact. Fix or dismiss before closing the period. * **Warning** - something looks off but may have an explanation. Worth a human glance. * **Info** - context for human review. Often confirms PX is suppressing a check on purpose (Airbnb-remitted tax, manual exception, and so on). You can filter the audit results by severity from the Findings Breakdown grid above the table. ## Expected, actual, and difference Each finding shows: * **Expected amount** - the value PX calculated. * **Actual amount** - the value recorded on the booking. * **Difference** - signed (positive when under-collected, negative when over-collected). The summary at the top of the audit aggregates these into the **Verdict** - the net direction across the run. ## Config source A short label identifying which configuration drove the expectation. Examples: * The tax came from your PMS's account-level taxes. * The tax came from a listing-level override. * A user channel sync override decided whether the tax applies. * The Airbnb tax remittance setting suppressed or required a tax. * The business model drove the expectation. The config source tells you exactly where to look if you want to change the expectation. The in-app finding card shows the precise source for every finding. ## Reasoning A short string explaining how PX arrived at the expected amount. Example: ``` expected = 0.085 * (accommodation_fare + cleaning_fee) = 0.085 * (1200.00 + 150.00) = 0.085 * 1350.00 = 114.75 ``` When the reasoning is shown inline, the formula uses real values from the booking. This is usually enough to understand whether the issue is in the booking or the configuration. ## How to triage a finding 1. Read the **reasoning** string - it tells you the formula. 2. Check the **config source** - that points to where the expectation came from. 3. Decide: * If the configuration is wrong, edit it. The next audit clears the finding. * If the booking is wrong, fix it in the PMS. The next audit re-checks. * If the booking is a one-off legitimate exception, **dismiss** the finding from the property detail page. Most findings fall into one of these three buckets. Findings that cannot be triaged in a few minutes usually point to a deeper configuration issue worth investigating. ## False positives False positives happen most often when: * The PMS catalog is incomplete (most common when the catalog has not yet been confirmed in PMS Configuration). * Channel sync overrides are missing for a channel that does not actually carry the tax. * Airbnb tax remittance is not configured. * A business model has a typo in commission percent or recurring charge category. In all these cases, fixing the configuration is the right answer. Dismissing the finding only hides the symptom. # Assign properties Source: https://docs.pxaccounting.com/business-models/assign Pick which properties a business model governs and re-assign safely. A business model is only useful once it is assigned to one or more properties. There are two places to assign: * **From the wizard** - the final review step has an **Assign properties** action. * **From the business model edit screen** - any time after creation. ## Assigning from the wizard The Create-a-business-model wizard's **Details & Listings** step has the listings picker built in. Tick the properties this model should govern, then continue to the review step. PX saves the assignment when you click **Save** on the review step. Assign listings inside the wizard ## Assigning from the model For an existing model: 1. Open **Business Models** in the sidebar. 2. Click the model name to open it. 3. Click **Assign properties**. 4. The picker dialog opens with a search box and a multi-select list of every property in your account. 5. Tick the properties this model governs. 6. Click **Save assignments**. PX persists the assignment immediately. If the model is **active**, audits and diagnostics start using the model for the assigned properties on their next run. ## One model per property Each property can only have **one** active business model at a time. Assigning a model to a property that already has one **replaces** the previous assignment. This is a deliberate constraint - it keeps audits unambiguous (PX always knows which model to use for a given reservation). If you need to change the model on an active property: 1. Assign the new model. The old assignment is removed. 2. Run an audit on a date range that overlaps with the change to check for transition findings. ## Effective dates Each business model has an activation date. PX uses this date plus the property's assignment record to decide which model applies to a given reservation: * The reservation's check-in date is compared against the active assignment's effective range. * If a property had Model A before March 1 and Model B after, March 1 is the cutoff and PX uses each model only for reservations whose check-in falls in its range. This means re-assigning models is safe for historical data - past audits remain consistent because they use the model that was active at the time. ## Bulk assignment patterns If you have many properties on the same management agreement: * **Same model for all** - create one model and assign it to every property. * **Tier-based** - create one model per tier (Standard 20%, Premium 25%, Trust 15%) and assign properties accordingly. * **Owner-based** - create one model per owner. Useful when each owner has bespoke commission terms. * **Channel-based** - one model with channel conditions on commission. Single model, dynamic rate. ## Removing an assignment To unassign a model from a property: * **From the model picker** - uncheck the property and Save. * **From the property** - currently you can only do this from the model side. To take a model out of service entirely without deleting it, click **Deactivate** on the model. This unassigns every property and sets status to Inactive. The model is preserved for history. ## What happens when you assign When you click **Save assignments** on an **active** model: 1. The assignment row is created (or updated) in PX. 2. A diagnostics batch job is queued for every newly assigned property. 3. Findings show up on the property detail page and in the next audit you run. When you assign on a **draft** model, no diagnostics run yet - PX waits for the model to be activated. ## Re-assigning after a model edit If you edit an active model's rules, PX creates a new version automatically. The version bump triggers a diagnostics re-run for every property assigned to the model so existing findings are recomputed against the new rules. You do not have to re-assign properties - assignments persist across versions. # Commission Source: https://docs.pxaccounting.com/business-models/commission Configure how PX represents the commission you take off each booking. The Commission section of a business model defines what the PMC takes off the top of each booking. PX validates calculated commission against your PMS during audits and flags any drift. ## Three sub-sections * **Confirmed reservations** - the standard path. The rate and timing for normal bookings. * **Canceled reservations** - cancellation-specific rules, often a lower rate. * **Minimum commission** - an optional floor that ensures you never earn less than a fixed amount per booking. The in-app wizard walks through each sub-section with field-level help. ## Confirmed and canceled For both, you specify: * **Default rate** - the commission percent applied to bookings on this model. * **Recognition** - when commission revenue is recognized in the GL. Confirmed bookings recognize at check-in, check-out, or per-night. Canceled bookings recognize at the cancellation date or the original check-in date. * **Owner tax (optional)** - charges the owner an additional VAT or GST on top of commission, common in jurisdictions that require it. * **Channel conditions (optional)** - per-channel overrides for channels that settle at a different rate. If a booking's channel matches a condition, that condition's rate replaces the default. A typical setup is a higher confirmed rate (say 20%) and a lower canceled rate (say 5-10%) that recognizes on the cancellation date. ## Minimum commission When the calculated commission falls below the floor you set, PX bumps it up to the floor amount. The audit reports the minimum as the expected value when this happens, so you see the difference clearly. ## Recognition timing in practice * **Check-in** - revenue lands when guests arrive. Easy to reconcile against bank deposits. * **Check-out** - revenue lands when guests leave. Useful when refunds are common between booking and check-in. * **Per-night** - amount divided across nights. Smooths long stays across month-end. Pick the timing that matches how your accountant closes the period. ## Audit findings related to commission When commission disagrees with what the audit expected, you will see findings noting the expected amount, the actual amount, the difference, and a reasoning string showing PX's calculation. The most common causes are channel-specific rate changes mid-period and configuration drift between PX and the PMS. See [Understanding findings](/audit/understanding-findings) for how to read these. # Create a business model Source: https://docs.pxaccounting.com/business-models/create Walk through the six-step wizard to build a new business model. Open **Business Models** in the sidebar and click **Create Business Model** to launch the wizard. Business Models list ## Step 1 - welcome A quick intro screen explaining what the wizard sets up. Click **Let's Get Started** to continue. The model is created in **Draft** status when you save it at the end of the wizard. Wizard welcome ## Step 2 - what counts as income Define which fees count as **income** vs **expense** for the purpose of net rental income. * **Income items** - check the items you want included in net rental income. Anything checked here adds to revenue when audits compute the income total. * **Expense items** - check the items you treat as deductions from gross revenue. * **Excluded items** (expandable) - everything else that PX detects but should not affect the income total. Useful for refunds, security deposits, and pass-through fees. You can re-classify items later - changing them creates a new version of the model. See [Net rental income](/business-models/net-rental-income) for the full reference. Wizard income step ## Step 3 - your commission rate Set the percentage you keep from each booking and when that revenue is recognized. * **Commission rate** - the default percent you earn (e.g. `20`). * **Recognition timing** - **When guest checks in**, **When guest checks out**, or **Daily** (spread per-night). * **Owner GST/VAT on commission** (optional) - charge the owner a tax on top of commission. Pick a category and percent. * **Per-channel overrides** (optional) - different rates for different channels (e.g. Airbnb 18%, Vrbo 22%). See [Commission](/business-models/commission) for the full reference. Wizard commission step ## Step 4 - recurring charges (optional) Add charges that recur on every reservation - cleaning, gift baskets, wifi, maintenance, owner-paid insurance, and so on. There are two buckets: * **Revenue items** - amounts that flow to you as income. * **Owner charges and expenses** - amounts the owner pays out. Each entry has a name, category, amount (fixed or variable), per-stay vs per-night basis, recognition timing, and optional owner VAT/GST and channel exclusions. You can skip this step entirely and add charges later. See [Trust account](/business-models/trust-account) for the full reference. Wizard recurring charges ## Step 5 - details and listings | Field | Meaning | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Name** (required) | A short label like `Standard Management 20%` or `Premium Beachfront`. Shows on every assigned property. | | **Description** | Optional notes. | | **Activation date** | The date the model becomes effective. Audits and diagnostics for reservations on or after this date use this model; reservations before it use whatever model was active then. | | **Listings** | Tick the properties this model should govern. You can also leave the picker empty here and assign later from the model detail page. | Wizard details and listings ## Step 6 - review and create A summary of every section. Click **Save** to persist the model. PX: 1. Validates required fields. 2. Saves the model in **Draft** status. 3. Once you activate and assign listings, queues a diagnostics run for every assigned property. Wizard review ## Editing later Open any model from the list to edit. Saving rule changes on an active model creates a new version (the original stays in place for historical audits). You can also: * **Duplicate** - clone the model with `Copy` appended to the name. Use this for what-if scenarios. * **Deactivate** - unassign all listings and set status to Inactive. * **Archive** - hide from the default list. Reversible if you remove the Archived filter. ## Common pitfalls * **Forgetting to set an activation date.** Without one, audits will not pick the model up. Set it on day one of the period the model covers. * **Duplicating instead of editing.** If you make a small rate change, edit and let PX version it - duplicate creates a parallel model that is not automatically reconciled with prior history. * **Activating without assigning properties.** Active + zero listings is allowed but does nothing useful. Assign before you walk away. * **Mixing income and expense items.** PX treats them as mutually exclusive. An item should appear in one bucket, not both. # Lifecycle and versioning Source: https://docs.pxaccounting.com/business-models/lifecycle How status transitions and versions work, and how to manage a model over time. A business model in PX is a long-lived object. It moves through statuses, accrues versions, and survives across countless audits. ## Status Four statuses with clear semantics: | Status | Meaning | | ------------ | ---------------------------------------------------------------- | | **Draft** | Work in progress. Not used by audits. | | **Active** | In use. Audits use this model for assigned properties. | | **Inactive** | Disabled, no assignments. Preserved for history. | | **Archived** | Hidden from the default list. Audit history still references it. | You move between these from the model edit screen. **Activate** flips Draft to Active and triggers a diagnostics run for assigned properties. **Deactivate** unassigns every property and flips status. **Archive** hides the model from the default list while keeping it readable for history. You cannot delete a model. ## Versioning Editing the configuration of an active model creates a new version automatically. * The previous version becomes immutable. * Past audits stay consistent because they reference the version that was active on the reservation's check-in date. Edits to the **name**, **description**, **activation date**, or **status** do not create a new version. Edits to the configuration (commission, trust account charges, net rental income, owner taxes) do. ## Version history Open a model and look for the **Version history** section. PX shows a list of versions with timestamps and a diff between adjacent versions. To "revert", edit the current version to match a prior one - PX records that as a new version with those values. ## Duplicate The **Duplicate** action creates a sibling model with `Copy` appended to the name. The duplicate starts in Draft, has no property assignments, and has its own version history starting from version 1. Use duplicate for what-if scenarios: "What if commission was 22% instead of 20%?" Build the duplicate, run an audit on a draft basis, and compare. ## Filters on the list page The **Business Models** list defaults to hiding archived models. The status filter dropdown has four options: **All (excl. Archived)**, **Active**, **Inactive**, and **Archived**. Use the column visibility picker to show or hide columns; your selection persists across visits. ## Diagnostics A few interactions trigger a diagnostics batch run in the background: * First-time activation of a draft model. * Property assignment to an active model. * A configuration edit on an active model (the version bump). Progress is visible on the **Home** page under **Accounting Diagnostic Job Runs**. If a batch is interrupted, retrying is safe - diagnostics are idempotent. # Net rental income Source: https://docs.pxaccounting.com/business-models/net-rental-income Choose which fees count as income and which count as expenses. Net rental income is the figure your owner statements report as **revenue**. The Net Rental Income section of a business model is where you tell PX which line items roll into that figure and which roll out. ## How it works For every reservation, PX iterates over every charge line. For each line: * If the line's **category** appears in **income items**, the amount adds to net rental income. * If the line's category appears in **expense items**, the amount subtracts from net rental income. * Otherwise the line is **excluded** - PX still tracks it for accounting integrity but does not change net rental income. The categories you check here come from your PMS configuration plus PX's standard buckets (accommodation, cleaning, pet fee, extra guest, refunds, and so on). ## The fields ### Income items Check every category that should add to revenue. Typical entries: * Accommodation fare * Cleaning fee (when the PMC retains it as revenue) * Pet fee * Extra guest fee * Early check-in / late check-out * Resort fees that you pass to the owner ### Expense items Check categories that should subtract from revenue. Typical entries: * Refunds * Promotional discounts you absorb * OTA service fees you reimburse * Channel processing fees passed through ### Excluded items Anything not checked above. PX shows them in an expandable list with a per-item config so you can document why they are excluded - for example, security deposits which are held in trust and never recognized. ## Examples **Standard 20% short-term rental management.** Income: accommodation, cleaning, pet fee. Expenses: refunds, channel commission. Excluded: security deposit, processing fees passed to the owner. **Cleaning kept by the cleaner.** Treat cleaning as **excluded** so it never shows on the owner statement. The cleaner invoices the owner directly outside PX. **Resort fee passed entirely to the owner.** Resort fee in income items, paired with a matching trust account expense charge so the net effect on the owner statement is zero. ## Validation PX does not enforce mutual exclusion at the schema level - you can technically check a category in both buckets - but doing so produces an inconsistent ledger. The audit will flag a `LEDGER_BALANCE_MISMATCH` finding if it cannot reconcile. If you are unsure, it is safer to: 1. Mark a category as **income** by default. 2. Add a corresponding **expense** trust account charge if you also need to subtract it. That way the income and expense are separate journal lines and easy to audit. ## Editing safely Changing income/expense membership creates a new version of the model. Reservations on or after the new version's effective date pick up the change; earlier reservations continue using the prior version. There is no downtime and no risk to historical audit results. # Business models overview Source: https://docs.pxaccounting.com/business-models/overview What a business model represents and the parts that make one up. A **business model** is PX's representation of your management agreement with the property owner. It tells PX how to translate raw PMS data into: * The **net rental income** you book as revenue. * The **commission** you take, including special rules for canceled bookings. * The **trust account** postings (cleaning, linen, maintenance, insurance, owner taxes, and so on). * Which **taxes** the PMC remits versus the owner. Without a business model, audits still run at the data-integrity level (revenue integrity, payment anomalies, charge splits). Ledger balance and owner statement reconciliation findings only fire when a business model is assigned. ## The three parts of a business model Which fees count as income vs expense. Confirmed and canceled rates, recognition, channel overrides. Recurring income and expense charges with PMC vs owner allocation. ## Status lifecycle A business model moves through four statuses: * **Draft** - work in progress. Diagnostics are deferred. Cannot be assigned to a property until activated. * **Active** - fully assigned and used by audits. The first transition from draft to active triggers a diagnostics batch run for every assigned property. * **Inactive** - all property assignments removed. The model still exists; you can re-activate or duplicate it. * **Archived** - hidden from the default list but kept for history and audit log integrity. ## Versioning Editing the rules of an active business model creates a **new version** automatically. Old versions stay frozen, so: * An audit run against a reservation always uses the version that was active on the reservation's check-in date. * Past results stay reproducible even after you update the model. * You can browse the version history from the model detail screen. A version bump triggers re-diagnostics for every assigned property so findings reflect the new rules going forward. ## What a model contains | Field | Required | Meaning | | ------------------- | ------------------- | -------------------------------------------------------------------------------- | | Name | Yes | Display name. | | Description | No | Free-text notes. | | Activation date | Yes (to run audits) | The date this model becomes effective. Earlier reservations use the prior model. | | Status | Yes | Draft, Active, Inactive, or Archived. | | Net rental income | No | Income items, expense items, excluded items. | | Commission | No | Confirmed, canceled, and minimum commission rules. | | Trust account | No | Recurring income and expense charges. | | Assigned properties | Auto | Number of properties using this model. | ## Where to start If this is your first model, walk through [Create a business model](/business-models/create). It uses a six-step wizard that explains each section as you go. If you already have one model and want to add another, you can either start fresh or **duplicate** an existing model from the list view and edit the copy. # Tax remittance Source: https://docs.pxaccounting.com/business-models/tax-remittance How the business model decides which taxes the PMC remits versus the owner. Tax remittance configuration in a business model controls which taxes the PMC is responsible for remitting. PX uses this to assign tax liability lines on the owner statement and during audits. This is **separate** from Airbnb tax remittance (currently Guesty-only), which lives on the Tax Configuration page and tracks marketplace-collected taxes. Read [Airbnb tax remittance](/tax-configuration/airbnb-remittance) for that. ## Two responsibility buckets * **PMC-remitted taxes** - the management company collects, holds, and remits to the authority. The owner sees a tax-collected line on their statement and a separate remittance to the authority. * **Owner-remitted taxes** - PX still tracks the tax for transparency, but the owner is responsible for remitting. The owner's payout includes the tax amount; remittance happens off-platform. A typical short-term rental setup has the PMC remit occupancy taxes and the owner remit any income tax on net rental income. ## Recognition For each remittance bucket you can specify: * **Recognition date** - when the liability is recognized in the GL. Common choices are `check_in`, `check_out`, or `accommodation_recognition_date` (matches whatever recognition you use for accommodation revenue). Matching tax recognition to accommodation recognition is the most common setup because it keeps tax liability in the same period as the revenue that triggered it. ## How this connects to Tax Configuration PX maintains tax rates and applicability rules under **Tax Configuration**. Those rates are read from your PMS (Guesty) or maintained in the OwnerRez catalog. The business model layer answers a different question: **once the tax exists, who remits it?** So the flow is: 1. **Tax exists** - configured in the PMS (Guesty) or in the OwnerRez catalog. 2. **Sync settings** - **Tax Configuration -> channel overrides** decide whether the tax syncs to a given channel. 3. **Marketplace remittance** - **Tax Configuration -> Airbnb remittance** decides whether Airbnb collects it on your behalf. 4. **PMC vs owner remittance** (this page) - decides who is on the hook for what is left. ## Audit findings related to tax remittance * **TAX\_AMOUNT\_MISMATCH** - the recorded tax does not match what the business model computed. * **MISSING\_TAX** - PX expected a tax based on the PMS configuration but the booking does not have one. * **UNEXPECTED\_TAX** - the booking has a tax PX cannot map to your configuration. Each finding tells you whether the expected value came from the PMS catalog, the channel override layer, or the business model's remittance configuration. This is useful when debugging "why did PX expect this amount?" # Trust account Source: https://docs.pxaccounting.com/business-models/trust-account Recurring income and expense charges, with PMC vs owner allocation. Trust account charges are recurring postings PX expects on every reservation. Use them to capture cleaning, linen, maintenance reserves, owner-paid insurance, and other recurring items - things that always happen but live outside the standard rental commission calculation. ## Two buckets * **Income charges** - things owed to the PMC or to a vendor. They credit the trust account. * **Expense charges** - things owed back to owners or paid out of trust. They debit the trust account. Each charge is independent. You can have as many of each as you need. ## What you set per charge The in-app **Add charge** dialog walks through each field with inline help. Conceptually, every charge captures: * A **name and category** for reporting and statement grouping. * **How the amount is determined** - either a fixed value you set, or the value taken from the matching PMS line item. * **When it is recognized** - on check-in, check-out, or spread across nights. Canceled bookings can use a different recognition. * **Who receives it** - the vendor (a third party like a cleaner), the owner, or split between them. The PMC's share is implied by what is left over. * **Optional VAT/GST on the charge** - billed to the owner. * **Channel conditions** - exclude specific channels where the charge does not apply. ## A few worked examples **Cleaning kept by an external cleaner.** Expense, variable per stay, allocated to the vendor. The owner's payout is unaffected; the cleaner is paid from trust. \*\*Maintenance reserve, $50 per stay, owner-funded.** Expense, fixed at $50 per stay, allocated to the owner. The owner's payout is reduced by \$50 each stay, accumulating in trust for repairs. \*\*Linen fee, $10 per night, PMC-retained.** Income, fixed at $10 per night. The PMC retains the charge. **Resort fee, split 60% owner / 40% PMC.** Income, variable per stay, split allocation. Owner takes 60%, PMC takes 40% (implied). ## Audit findings related to trust account If the business model expects a charge that is missing on a booking, or the amount differs from the model's calculation, you will see findings on the property detail page and in audits. Each finding includes the expected amount, the actual amount, and a reasoning string showing how the expected value was computed. ## When trust account becomes essential Trust account configuration is what enables PX's owner statement reconciliation findings. Without it: * Audits still detect data integrity issues (zero rent, payment anomalies, missing payments). * Audits will not detect that an owner statement is off because a recurring charge was never posted. The latter category catches the most expensive operational mistakes, so investing in trust account configuration pays back quickly. # Key concepts Source: https://docs.pxaccounting.com/get-started/concepts How properties, business models, taxes, and audits fit together in PX Accounting. A short tour of the words you will see across PX Accounting and how each piece relates to the others. ## Property A **property** (sometimes called a **listing**) is a single rentable unit. Properties live in your PMS - PX syncs them in and stores the canonical fields you need: * Name, address, thumbnail. * Bedrooms, bathrooms, accommodates, property type. * Base nightly rate and cleaning fee (Guesty only - OwnerRez does not expose these). * Active/inactive status. * The owner record (when one is mapped in your PMS). * The business model assigned to it. * An **auto-fix** toggle. You can also add properties manually from the Properties page if you have something off-PMS, but the typical flow is sync from PMS. ## Business model A **business model** is PX's representation of your management agreement with the owner. It tells PX how to translate raw PMS data into accounting postings: * Which fees count as **net rental income** vs expenses. * The **commission rate** (confirmed and canceled bookings can have different rules) and when it is recognized (check-in, check-out, or daily). * Optional **owner taxes** on commission, in jurisdictions that require them. * **Recurring charges** in the trust account - cleaning, linen, maintenance, insurance, and so on - with PMC vs owner allocation. * **Tax remittance** behavior, including which taxes the PMC remits and which the owner remits. Properties without a business model still get audited at the data-integrity level, but ledger balance and owner statement findings only run when a model is assigned. Business models are **versioned**. Editing an active model creates a new version automatically; old versions are preserved so audit history stays consistent. ## Tax configuration Tax configuration in PX has three independent layers: 1. **PMS mirror (read-only).** PX shows the taxes configured on your PMS account and per listing. You change these in your PMS, not in PX. 2. **Channel sync overrides (PX-only, user-writable).** Per-tax, per-channel toggles you set inside PX. They are used during audits to decide whether to expect a tax on a given booking. PX does **not** push these back to your PMS. 3. **Airbnb tax remittance (PX-only, user-writable).** A four-step wizard you complete inside PX that records which taxes Airbnb collects and remits on your behalf. Findings for those taxes are suppressed on Airbnb bookings. Again, this is stored in PX only and is not pushed to your PMS. For some PMSes the tax mirror is built from your booking history rather than read directly from the PMS. The PMS catalog (under PMS Configuration) is the source of truth in that case - taxes are inferred for you and you confirm or edit them inside PX. ## Audit An **audit** is a run of PX's diagnostic checks across a date range and (optionally) a single listing. PX queues a background job, then returns: * A **summary** - reservations audited, issues found, and a verdict (clean, underpaid, overpaid). * A list of **reservations** with their charges and findings. * A **findings breakdown** by finding type. Each **finding** has: * A **severity** - error, warning, or info. * A **type** - missing tax, fee mismatch, payment anomaly, etc. * An **expected** and **actual** amount. * A **reasoning** string that explains the formula PX used. * A **source** indicating which configuration the expectation came from. Audits do not modify your PMS. They are read-only diagnostics. ## Auto-fix **Auto-fix** is PX's automatic resolution of issues that are safe to fix without a human review. You can toggle it: * **Globally** from the Properties page - the toggle in the table header applies to every property. * **Per property** - the toggle on each row, or on the property detail page, controls just that listing. When auto-fix is on for a property, unresolved issues show **Fix in Progress** instead of **Start Fix** / **Dismiss** buttons. PX processes them in the background. ## How PMS data flows in ``` Your PMS | | OAuth or API key v Settings -> Connect Your PMS | | Sync triggered v Properties + Reservations + Charges + Payments | v Audit (against business model + tax config + PMS catalog) | v Findings -> Property detail / Audit page ``` PX is **not a ledger or bookkeeping engine**. It does not maintain accounts, post journal entries, or replace your accounting system. PX *reads* your PMS data and *audits* it against your business model and tax configuration. Where your PMS exposes journal entries, PX uses them directly. Where it does not, PX works from per-charge data (charges, payments, refunds, deposits) to compute what the postings should look like for audit purposes only. The audit logic is the same either way; only the data source differs. ## Where each concept lives in the UI | Concept | Page | Notes | | --------------------- | -------------------------------------------------------------- | ------------------------------------ | | Property | **Properties** (list and detail) | Click a row to drill in. | | Business model | **Business Models** | List, create, edit, version, assign. | | PMS tax mirror | **Tax Configuration** -> Account-level / Per-listing | Read-only; reflects your PMS. | | Channel sync override | **Tax Configuration** -> Per-listing | Toggle per tax, per channel. | | Airbnb remittance | **Tax Configuration** -> top wizard card | Singleton per account. | | OwnerRez catalog | **PMS Configuration** | Tax/fee/commission baseline. | | Audit | **Financial Audit** | Run, results, PDF export. | | Findings | Property detail (per property) or Financial Audit (across all) | | | Settings | **Settings** | PMS, timezone, billing, danger zone. | # Quickstart Source: https://docs.pxaccounting.com/get-started/quickstart Connect your PMS and run your first audit. This walkthrough takes you from a fresh account to a complete audit. Set aside about 15 minutes the first time. Open [pxapp.net](https://pxapp.net) and sign in. Use Google, Microsoft, or email - whichever you registered with. First-time visitors are taken straight to **Settings** because PX needs a PMS connection before it can do anything useful. On the **Settings** page, find the **Connect Your PMS** card and pick your provider. Each PMS has a dedicated setup guide: * [Connect Guesty](/integrations/connect-guesty) * [Connect OwnerRez](/integrations/connect-ownerrez) * [Connect Hostaway](/integrations/connect-hostaway) * [Connect Hospitable](/integrations/connect-hospitable) * [Connect Hostfully](/integrations/connect-hostfully) * [Connect Lodgify](/integrations/connect-lodgify) * [Connect Uplisting](/integrations/connect-uplisting) Once connected, the **Integration Status** panel shows a green **Webhooks** row reading *Registered and active*, and your properties are pulled in automatically. Connect Your PMS Open **Tax Configuration**. PX reads the taxes you have set up in your PMS and shows them in two tabs: * **Account-level** - taxes that apply to every listing. * **Per-listing** - listings grouped by whether they inherit account taxes or override them. Most users only need to do two things on this page: 1. **Set channel sync overrides** if a tax should not sync to specific channels (Airbnb, Booking.com, etc.). PX uses these overrides during audits. 2. **Run the Airbnb remittance wizard** to tell PX which taxes Airbnb collects on your behalf. Findings for Airbnb-remitted taxes are suppressed once configured. Read [Tax Configuration overview](/tax-configuration/overview) before changing anything in production. Open the **Financial Audit** page. * Pick a **start date** and **end date** (the range cannot exceed 62 days). * Optionally pick one **listing** (or leave as "All Listings"). * Click **Generate Audit**. PX queues a background job and shows a progress card. When it finishes you see: * Three summary cards: **Reservations Audited**, **Issues Found**, **Verdict**. * A results table - one row per reservation, expandable to show line items and findings. * A **Findings Breakdown** card with counts by finding type. * A **Download Report** button to export the audit as a PDF. Read [Run an audit](/audit/run-an-audit) for what each finding type means. Audit results ## Where to go next Severity, expected vs actual, and what each finding means. Add a card or bank account to keep your subscription active. Timezone, integration status, and account preferences. # Welcome to PX Accounting Source: https://docs.pxaccounting.com/get-started/welcome What PX Accounting does, who it is for, and what to read next. PX Accounting is a trust accounting and audit autopilot for property management companies. It connects to your PMS, inspects every reservation, and flags discrepancies in taxes, fees, commissions, payouts, and balances - so every dollar lines up before you close the books. ## What PX does * **Mirrors your PMS configuration.** PX reads the taxes, fees, and channel commissions you have set up in your PMS so audits run against the same rules you use day to day. * **Models your accounting.** Business models translate PMS data into the income, expense, and trust account postings your accountant expects. * **Audits every reservation.** Run an audit across a date range and PX checks each booking against your business model, your tax configuration, and your PMS settings. * **Surfaces issues per property.** Open any property to see unresolved findings, mark fixes in progress, and track resolution over time. ## Who it is for PX Accounting is built for property management companies (PMCs) - the people who manage other owners' rentals and need to: * Reconcile guest payments against owner payouts every period. * Verify that the right taxes were collected and remitted on every booking. * Prove that commissions and recurring charges match the management agreement. * Catch missed deposits, payment anomalies, and ledger imbalances before they become disputes. If you operate one or two of your own listings, PX may be more than you need. If you manage 5 or 5,000 properties on behalf of owners, PX scales with you. ## Supported integrations PX Accounting connects to: * **Guesty** * **OwnerRez** * **Hostaway** * **Hospitable** * **Hostfully** * **Lodgify** * **Uplisting** Each PMS has a dedicated setup guide. Pick yours under [Connect your PMS](/integrations/overview). If your PMS is not on this list, write to [support@pxaccounting.com](mailto:support@pxaccounting.com) - new integrations are added regularly. ## What to read next Connect your PMS, sync properties, and run your first audit. Properties, business models, taxes, audits - how they fit together. # Connect Guesty Source: https://docs.pxaccounting.com/integrations/connect-guesty Connect your Guesty account to PX Accounting with an integration token from the Guesty Marketplace. You connect Guesty to PX Accounting through the **Guesty Marketplace**: you authorize PX Accounting inside Guesty, Guesty gives you a one-time key, and you paste that key into PX. ## Before you start You will need an admin user on your Guesty account. In PX, open **Settings**. In the **Connect Your PMS** card, pick **Guesty**. Guesty in the PMS picker The connect form opens below the provider grid, reading *Connect your Guesty account by pasting the API key Guesty gives you*. **Back to provider selection** returns you to the grid. Connect Guesty with an integration token ## Connect Guesty 1. Click **Open PX Accounting in Guesty** - this opens PX's [partner page in Guesty](https://app.guesty.com/integrations/partners/pxaccounting). Click **Connect** there. 2. Guesty shows you an API key. Click **Copy**. 3. Back in PX, paste it into **Integration token** and click **Connect Guesty**. Copy the key before you close Guesty's dialog. Guesty shows it once and will not show it again. If you miss it, or if more than about 3 hours pass, disconnect PX Accounting in Guesty and connect again to get a new one. Guesty's dialog calls it an API key and PX labels the field **Integration token** - they are the same value. PX exchanges it for the credentials it stores, which is why there is nothing left to manage afterwards and the connected card has no editable fields. The connection grants read access to listings, reservations, and accounting data. PX never writes back to Guesty. ## Confirming the connection Once connected, the **Guesty API Credentials** card shows *Your Guesty account is connected and syncing properties*, along with the date the connection was established. The **Integration Status** card below it reports a single health row: * **Webhooks** - green check when it reads *Registered and active*. PX has registered its webhook endpoint with your Guesty account, so listing and reservation changes reach PX as they happen. Guesty connected The card also shows a read-only **Guesty Account ID**, with your Guesty account name beneath it. Quote that ID if you contact Guesty support. If the field reads *Not read from Guesty yet. It appears after the next sync*, your connection predates the field and it fills in on the next daily sync. ## What PX reads from Guesty PX has **read-only** access. Nothing is written back. **Properties** - id, name, address, bedrooms / bathrooms / accommodates, currency, default cleaning fee, active flag, thumbnail. *Synced on connect, on Guesty `listing.*` webhooks, and on Properties -> Sync from Guesty.* **Reservations** - id, listing, status, check-in / check-out, booking date, guest name and count, channel, confirmation code, currency, totals (amount, paid, balance, refunded), cancellation snapshot. *Synced on demand (Property detail), on `reservation.*` webhooks, and during audits.* **Per-charge financial data** - line amount and type (accommodation / fee / expense / tax), taxable flag, per-night accommodation breakdown, per-reservation totals. *Synced with the parent reservation.* **Tax catalog** - account-level and per-listing taxes: rates, applicability, metadata. *Synced on Tax Configuration -> Refresh from PMS.* **Webhook events** - `listing.new` / `updated` / `removed`, `reservation.new` / `updated`, and `payments.*` (acknowledged - financial state is re-read from the reservation, not the webhook payload, so a missed event never causes drift). ## Reconnecting Disconnect PX Accounting on its [partner page in Guesty](https://app.guesty.com/integrations/partners/pxaccounting), connect again to get a fresh key, then paste it into PX. The **Integration token** field only appears when no connection exists, so if you already have a new key in hand, click **Delete** in PX first to get the form back. ## Removing the connection Open **Settings**, go to the **Guesty API Credentials** card, and click **Delete**. Confirm in the dialog. This: * Removes the stored credentials. * Unregisters the webhook. * **Removes all synced properties.** Deleting your Guesty credentials also deletes your synced properties. This cannot be undone. Your business models, tax configuration, and audit history are account-level and are not removed by deleting the PMS connection. ## Troubleshooting **Webhooks row reports a failure.** PX could not register its webhook. Most often this is a Guesty plan limitation - some plans cap the number of webhooks. Remove an unused webhook in Guesty and retry from the Integration Status card. **Connect Guesty fails after pasting the token.** The key has already been used or has expired - Guesty keys are single-use and last about 3 hours. Disconnect PX Accounting in Guesty, connect again for a fresh key, and paste that one. **Sync runs but no properties appear.** Check that the listings are marked active in Guesty. Also confirm the Guesty user that authorized the connection has visibility into the listings - sub-accounts may be restricted. **The Guesty Account ID field is empty.** Expected on connections made before PX started recording the account ID. It appears after the next daily sync. ## What's next What gets synced when - and what stays cached. Browse your synced portfolio and toggle auto-fix. # Connect Hospitable Source: https://docs.pxaccounting.com/integrations/connect-hospitable Generate a Hospitable Personal Access Token and connect it to PX Accounting. PX Accounting connects to Hospitable (formerly Smartbnb) with a Personal Access Token (PAT) you generate inside Hospitable. Hospitable in the PMS picker ## Before you start You will need: * A paid Hospitable plan. The Essentials plan does not include public API access; if you are on Essentials, upgrade first. * An owner-level login. ## Step 1 - generate a Personal Access Token 1. Sign in to Hospitable: [my.hospitable.com](https://my.hospitable.com). 2. In the sidebar, open **Apps** (or **Settings** -> **Integrations**). 3. Click **API access**. 4. Switch to the **Access tokens** tab. 5. Click **+ Add new**. 6. Give the token a name like `PX Accounting` and create it. 7. Copy the token. For details, see Hospitable's article: [Accessing the Public API with a Personal Access Token](https://help.hospitable.com/en/articles/8609392-accessing-the-public-api-with-a-personal-access-token-pat). Personal Access Tokens expire after **1 year**. Set a reminder to re-issue and update PX before the expiry, or audits will start failing. ## Step 2 - paste the token into PX 1. In PX, open **Settings**. 2. In the **PMS Connection** card, pick **Hospitable**. 3. Paste the **Personal Access Token**. 4. Click **Save credentials**. PX validates the token and the **Integration Status** panel shows three lights: **Admin**, **OAuth**, and **Webhook**. ## What PX reads from Hospitable PX has **read-only** access. Nothing is written back. **Properties** - id, name, address, bedrooms / bathrooms / max guests, property type, currency, active flag, thumbnail. *Synced on connect, on listing webhooks, and on Properties -> Sync from Hospitable.* **Reservations** - id, listing, status, check-in / check-out, booking date, guest details (subject to channel masking), guest count breakdown, channel and confirmation codes, currency, totals. *Synced on demand, on reservation webhooks, and during audits.* **Per-charge financial data** - per-night accommodation, cleaning / pet / extra-guest / custom fees, taxes per type, channel commission and host service fee, guest-paid vs. host-payout split. *Synced with the parent reservation.* **Tax catalog** - rates, names, applicability per listing. *Synced on Tax Configuration -> Refresh from PMS.* **Webhook events** - reservation created / updated / canceled, listing created / updated, channel connection changes. Hospitable exposes per-night pricing (not just the stay average), so audits can verify accommodation amounts to the day. ## Removing the connection Open **Settings**, scroll to the **PMS Connection** card, and click **Delete**. This removes the token from PX and unregisters webhooks. ## Troubleshooting **Admin status is red.** The token is wrong or has been revoked in Hospitable. Generate a new PAT and update PX. **Token expired.** Hospitable PATs expire after 1 year. Re-issue and update PX. **API access is disabled.** Hospitable's Essentials plan does not include public API. Upgrade to a paid tier and try again. # Connect Hostaway Source: https://docs.pxaccounting.com/integrations/connect-hostaway Generate a Hostaway API key and connect it to PX Accounting. PX Accounting connects to Hostaway with an Account ID and a Secret Key generated inside Hostaway. Hostaway in the PMS picker ## Before you start You will need: * An admin user on your Hostaway account with permission to manage the Public API. * The ability to copy the Secret Key once it is shown - Hostaway only displays it in the modal at creation time. ## Step 1 - generate Hostaway credentials 1. Sign in to Hostaway. 2. Go to **Settings** -> **Hostaway API**. * Direct link: [dashboard.hostaway.com/settings/hostaway-api](https://dashboard.hostaway.com/settings/hostaway-api) 3. Click **Create**. 4. Pick **Hostaway Public API** as the partner (this is what PX uses). 5. Hostaway shows your **Account ID** and a **Secret Key** in a modal. The Secret Key is shown **only once**. Copy it before closing the modal. If you lose it, generate a new one. For background, see Hostaway's article: [Public API account and secret key](https://support.hostaway.com/hc/en-us/articles/360002576293). ## Step 2 - paste credentials into PX 1. In PX, open **Settings**. 2. In the **PMS Connection** card, pick **Hostaway**. 3. Paste your **Account ID** and **Secret Key**. 4. Click **Save credentials**. PX validates the credentials and the **Integration Status** panel shows three lights: **Admin**, **OAuth**, and **Webhook**. ## What PX reads from Hostaway PX has **read-only** access. Nothing is written back. **Properties** - id, name, address (with lat / lng), bedrooms / bathrooms / max guests, property type, currency, cleaning fee, base nightly rate, minimum-stay default, active flag, thumbnail. *Synced on connect, on `listing.*` webhooks, and on Properties -> Sync from Hostaway.* **Owners** - id, first / last name, email, phone, properties owned. *Synced with the parent property.* **Reservations** - id, listing, status, check-in / check-out, booking date, guest details, guest count breakdown, channel and confirmation codes, currency, totals (amount, paid, balance, refunded), cancellation snapshot. *Synced on demand, on `reservation.*` webhooks, and during audits.* **Per-charge financial data** - line amount and type (accommodation / cleaning / fee / tax), taxable flag, per-night accommodation breakdown, per-reservation totals (subtotal, taxes, host service fee, commission, owner payout, net income), channel-platform fees, security deposit and damage protection. *Synced with the parent reservation.* **Tax catalog** - account-level rates, applicability, and per-channel sync settings. *Synced on Tax Configuration -> Refresh from PMS.* **Webhook events** - listing created / updated / deleted, reservation created / updated / canceled, payment received / refunded. ## Removing the connection Open **Settings**, scroll to the **PMS Connection** card, and click **Delete**. This removes the credentials from PX and unregisters webhooks. ## Troubleshooting **Admin status is red after saving credentials.** The Account ID is wrong or the API token has been revoked. Generate a new one. **Webhook status is red.** Hostaway plan limits or webhook endpoint conflicts can cause this. Confirm your plan includes webhooks and click **Refresh**. **Access tokens stop working after a long time.** Hostaway access tokens (derived from key + secret) expire after 24 months. Re-issue the key in Hostaway and update PX. # Connect Hostfully Source: https://docs.pxaccounting.com/integrations/connect-hostfully Get your Hostfully API key and connect it to PX Accounting. PX Accounting connects to Hostfully with an agency-level API key. The key sends as the `X-HOSTFULLY-APIKEY` HTTP header. Hostfully in the PMS picker ## Before you start You will need: * A Hostfully plan that includes public API access. Not all plans do - if your agency settings have no API key field, contact [api@hostfully.com](mailto:api@hostfully.com) to request access. * Agency-admin permissions in Hostfully. ## Step 1 - locate your API key 1. Sign in to Hostfully: [platform.hostfully.com/agency.jsp](https://platform.hostfully.com/agency.jsp). 2. Open the **Agency Settings** page. 3. Scroll to the **API Key** field and copy the value. If the field is empty or missing: * Confirm your Hostfully plan includes API access. * Email [api@hostfully.com](mailto:api@hostfully.com) to request the key. For background, see Hostfully's articles: [Exporting data through the API](https://help.hostfully.com/en/articles/3453789-exporting-data-through-the-hostfully-api) and the developer reference at [dev.hostfully.com](https://dev.hostfully.com/reference/getting-started). ## Step 2 - paste the key into PX 1. In PX, open **Settings**. 2. In the **PMS Connection** card, pick **Hostfully**. 3. Paste the **API Key**. 4. Click **Save credentials**. PX validates the key and the **Integration Status** panel shows three lights: **Admin**, **OAuth**, and **Webhook**. ## What PX reads from Hostfully PX has **read-only** access. Nothing is written back. **Properties** - uid, name, address (with lat / lng), bedrooms / bathrooms / accommodates, property type, currency, active flag, thumbnail. *Synced on connect, on `property` webhooks, and on Properties -> Sync from Hostfully.* **Owners** - id, first / last name, email, phone, properties managed. *Synced with the parent property.* **Reservations** - uid, property, status, check-in / check-out, booking date, guest details, guest count breakdown, channel and confirmation code, currency, totals, cancellation snapshot. *Synced on demand, on `reservation` webhooks, and during audits.* **Per-charge financial data** - line amount and type (accommodation / cleaning / fee / tax / expense), taxable flag, per-night accommodation breakdown, per-reservation totals (subtotal, taxes, channel commission, owner payout), payments and refunds. *Synced with the parent reservation; payments / refunds also via `payment` webhooks.* **Tax catalog** - agency-level rates, names, applicability per property. *Synced on Tax Configuration -> Refresh from PMS.* **Webhook events** - lead / quote created, reservation created / updated / canceled, property created / updated, payment created / refunded. ## Removing the connection Open **Settings**, scroll to the **PMS Connection** card, and click **Delete**. The key is wiped from PX and webhooks are unregistered. ## Troubleshooting **Admin status is red.** The API key is wrong or has been rotated in Hostfully. Get the latest value from agency settings and update PX. **API key field is missing in Hostfully.** Plan limitation. Contact [api@hostfully.com](mailto:api@hostfully.com) to enable API access on your account. **Sandbox vs production confusion.** Hostfully requires development to start in sandbox; production keys are issued separately. Make sure you are using the production key, not a sandbox one. # Connect Lodgify Source: https://docs.pxaccounting.com/integrations/connect-lodgify Get your Lodgify API key and connect it to PX Accounting. PX Accounting connects to Lodgify with an API key from your Lodgify account settings. Lodgify in the PMS picker ## Before you start You will need: * A Lodgify plan that includes public API access. Some plans do not - if the API key field is empty, you will need to contact Lodgify support to have one provisioned. * Owner or admin login. ## Step 1 - locate your API key 1. Sign in to Lodgify. 2. Open **Settings** -> **Public API**. 3. Copy the **API key** shown on the page. For background, see Lodgify's docs: [Authorization](https://docs.lodgify.com/docs/authorization). If the API key field is empty: * Contact Lodgify support and ask them to provision an API key for your account. Self-serve issuance is not always available. * Confirm your plan includes API access. The Lodgify API key carries full read and write scope. Treat it as a production credential. ## Step 2 - paste the key into PX 1. In PX, open **Settings**. 2. In the **PMS Connection** card, pick **Lodgify**. 3. Paste the **API key**. 4. Click **Save credentials**. PX validates the key and the **Integration Status** panel shows three lights: **Admin**, **OAuth**, and **Webhook**. ## What PX reads from Lodgify PX has **read-only** access. The Lodgify key technically carries write scope, but PX never uses it - nothing is written back. **Properties** - id, name, address, bedrooms / bathrooms / max guests, property type, currency, active flag, thumbnail. *Synced on connect, on `property` webhooks, and on Properties -> Sync from Lodgify.* **Owners** - id, first / last name, email, phone. *Synced with the parent property.* **Reservations** - id, property, status, check-in / check-out, booking date, guest details, guest count, channel and confirmation code, currency, totals. *Synced on demand, on `booking` webhooks, and during audits.* **Per-charge financial data** - line amount and type (accommodation / fee / tax / discount), taxable flag, per-night accommodation breakdown, per-reservation totals, payments. *Synced with the parent reservation; payments also via `payment` webhooks.* **Tax catalog** - rates, names, applicability per property. *Synced on Tax Configuration -> Refresh from PMS.* **Webhook events** - booking created / updated / canceled, property created / updated, payment received / refunded. ## Removing the connection Open **Settings**, scroll to the **PMS Connection** card, and click **Delete**. The key is wiped from PX and webhooks are unregistered. ## Troubleshooting **Admin status is red.** The API key is wrong or has been rotated. Pull the latest value from Lodgify and update PX. **API key field is empty in Lodgify.** Contact Lodgify support to have one provisioned. **Webhook status is red.** Verify your Lodgify plan includes webhook delivery. Click **Refresh** in PX after confirming. # Connect OwnerRez Source: https://docs.pxaccounting.com/integrations/connect-ownerrez Authorize PX Accounting with OwnerRez and build your audit baseline catalog. OwnerRez uses a one-click OAuth flow. There is nothing to copy and paste - you click a button in PX, sign in to OwnerRez, and grant access. OwnerRez in the PMS picker ## Before you start You will need: * An OwnerRez account with API access enabled (most plans include this; contact OwnerRez support if API is locked). * An owner-level login - sub-users may not have permission to authorize third-party apps. ## Step 1 - authorize PX 1. In PX, open **Settings**. 2. In the **Connect Your PMS** card, pick **OwnerRez**. 3. Click **Connect with OwnerRez**. 4. Sign in to OwnerRez when prompted. 5. On the consent screen, click **Authorize PX**. Authorize PX on OwnerRez OwnerRez redirects you back to PX. The card becomes **OwnerRez Connected**, subtitled *Your OwnerRez account is connected via OAuth*, and the **Integration Status** panel below shows a **Webhooks** row reading *Registered and active*. OwnerRez connected ## Step 2 - confirm the OwnerRez catalog This step is unique to OwnerRez. **You must do it before audits return useful results.** The moment you authorize the connection, PX: 1. Scans your last 18 months of bookings. 2. Infers a catalog of taxes, fees, and commission rates from the line items it sees. 3. Loads them into your **OwnerRez Catalog** marked `inferred`, ready for review. You then: 1. Open **PMS Configuration** in the sidebar. 2. Walk through each row and: * Click **Confirm** if the inferred rate matches what you actually charge. * **Edit** the rate, unit (percent vs fixed), or applicability scope if needed. * Click **Add row** for any tax or fee PX did not pick up. * **Archive** entries that are out of date. 3. Use **Detect from bookings** later if you want to rescan after a rate change or new booking history. Entries can be in one of four statuses: * **inferred** - PX detected this from booking history. Not yet used by audits. * **user-added** - you created it manually. * **confirmed** - reviewed and approved. Used by audits. * **archived** - hidden, not used. Audits use **confirmed** and **user-added** rows only. If the catalog has no usable rows, audits short-circuit with a `CATALOG_EMPTY` finding instead of running. See [OwnerRez Catalog](/pms-configuration/ownerrez-catalog) for the full UI walkthrough. Where do you actually configure these rates? On OwnerRez itself - **Settings -> Taxes** (account-wide), **Settings -> Surcharges** (fees), and **Property Management -> Setup & Configuration** (owner commissions). PX's catalog is your audit baseline; OwnerRez is the system of record. ## What PX reads from OwnerRez PX has **read-only** access. Nothing is written back. **Properties** - id, name, address, bedrooms / bathrooms / max guests, currency, owner id. *Synced on connect and on OwnerRez `property` webhooks.* **Owners** - id, first / last name, email, properties owned. *Synced with the parent property.* **Reservations (bookings)** - id, property, status, check-in / check-out, guest name and count, channel and the channel's reservation number, currency, totals (amount, paid, balance, refunded, host fees), block flag, cancellation snapshot. *Synced on demand, on `booking` webhooks, and during audits.* **Per-charge financial data** - line amount and type (accommodation / surcharge / tax / expense), taxable flag, per-charge owner-vs-commission split. Plus payments, refunds, and deposits read separately so payouts can be reconciled to bookings. *Synced with the parent booking and on `payment` / `refund` / `deposit` webhooks.* **Tax / fee / commission catalog** - inferred from the last 18 months of bookings, then confirmed by you in **PMS Configuration -> OwnerRez Catalog**. OwnerRez's UI stays the system of record; PX's catalog is the audit baseline. *Built on **Detect from bookings**; not synced thereafter.* **Webhook events** - `entity_create` / `entity_update` / `entity_delete` on bookings, properties, payments, refunds, and deposits, plus `application_authorization_revoked` (cleanly tears down the OAuth credentials). ## Removing the connection Open **Settings**, go to the **OwnerRez Connected** card, and click **Disconnect**. Confirm in the dialog. This revokes the OAuth token, unregisters webhooks, and **removes your synced properties**. Your business models, tax configuration, and audit history are account-level and stay in place, and you can reconnect at any time. ## Troubleshooting **OAuth pop-up does not return to PX.** Pop-up blockers are a common cause. Allow pop-ups for `pxapp.net` and try again. **Webhook status is red.** OwnerRez may have rejected the webhook URL. Verify your OwnerRez plan includes webhook access and click **Refresh**. **Audits return no results.** The OwnerRez catalog is probably empty. Open **PMS Configuration**, run **Detect from bookings**, and confirm at least the taxes and any commission rules you charge. **A booking has no inferred catalog rules.** This is expected for one-off charges (cleaning fee on a single trip, manual adjustment). PX only infers rules that repeat. Add custom rows in the catalog for anything systematic. ## What's next Confirm and edit the audit baseline. Once the catalog is confirmed, run your first audit. # Connect Uplisting Source: https://docs.pxaccounting.com/integrations/connect-uplisting Get your Uplisting API key and connect it to PX Accounting. PX Accounting connects to Uplisting with an API key from your Uplisting account. Uplisting in the PMS picker ## Before you start You will need: * An Uplisting account. * Owner-level login. ## Step 1 - generate or copy your API key 1. Sign in to Uplisting. 2. Go to [app.uplisting.io/connect/api](https://app.uplisting.io/connect/api). * First-time visitors: click to generate a key. * Returning visitors: copy the existing key. For background, see Uplisting's docs: [API & Webhooks](https://support.uplisting.io/docs/api). Uplisting issues a single API key per account, with full scope. **Rotating it breaks every existing integration simultaneously**, including any other tools you have connected. Coordinate before rotating. ## Step 2 - paste the key into PX 1. In PX, open **Settings**. 2. In the **PMS Connection** card, pick **Uplisting**. 3. Paste the **API key**. 4. Click **Save credentials**. PX validates the key and the **Integration Status** panel shows three lights: **Admin**, **OAuth**, and **Webhook**. ## What PX reads from Uplisting PX has **read-only** access. Nothing is written back. **Properties** - id, name, address, bedrooms / bathrooms / max guests, property type, currency, active flag, thumbnail. *Synced on connect, on listing webhooks, and on Properties -> Sync from Uplisting.* **Owners** - id, first / last name, email, phone, properties owned. *Synced with the parent property.* **Reservations** - id, listing, status, check-in / check-out, booking date, guest details, guest count breakdown, channel and confirmation code, currency, totals. *Synced on demand, on booking webhooks, and during audits.* **Per-charge financial data** - line amount and type (accommodation / cleaning / fee / tax / discount), taxable flag, per-night accommodation breakdown, per-reservation totals, payments. *Synced with the parent reservation; payments also via payment webhooks.* **Tax catalog** - rates, names, applicability per listing. *Synced on Tax Configuration -> Refresh from PMS.* **Webhook events** - booking created / updated / canceled, listing created / updated, payment received / refunded. ## Removing the connection Open **Settings**, scroll to the **PMS Connection** card, and click **Delete**. The key is wiped from PX and webhooks are unregistered. ## Troubleshooting **Admin status is red.** The API key is wrong or was rotated in Uplisting. Get the latest value and update PX. **Other integrations broke after rotating the key.** Expected. Uplisting uses a single shared key. Update every integration that uses it, including PX. # How sync works Source: https://docs.pxaccounting.com/integrations/how-sync-works When PX pulls data from your PMS and how to refresh. PX syncs in three modes: **on connect**, **on demand**, and **via webhooks**. ## On connect The first sync runs automatically as soon as PX validates your credentials. PX fetches: * Account metadata - the OAuth account ID and the admin user. * Your full property catalog. * A tax / fee / commission catalog (the way it is built depends on the PMS - see the relevant **Connect** page). Reservations and per-booking financial data are pulled on demand and via webhooks from then on - they are not bulk-loaded at connect time. ## On user action These actions hit your PMS in real time: | User action | What gets fetched | | --------------------------------------------- | ----------------------------------------------------------------- | | Properties -> **Sync from \[PMS]** | Full listing catalog. Idempotent upsert by PMS ID. | | Properties -> **Sync owners** (when present) | Owner records, mapped to properties. | | Property detail -> **Reservations** tab | Reservations within the selected date filters. | | Property detail -> open a reservation folio | Per-reservation charges, payments, journal entries (Guesty only). | | Tax Configuration -> **Refresh from PMS** | Account-level and per-listing taxes (Guesty). | | PMS Configuration -> **Refresh from PMS** | Fees, taxes, commissions catalog (Guesty). | | PMS Configuration -> **Detect from bookings** | Catalog inference from history (OwnerRez). | | Audits -> **Generate Audit** | Reservations in the audit range plus their dependencies. | Each "on demand" call is rate-limit aware. If your PMS rejects with a 429, PX surfaces a banner with a countdown and the action's button stays disabled until the cooldown ends. ## Via webhooks PX subscribes to PMS webhooks so changes propagate without you clicking sync: * **Guesty** - reservation created, reservation changed, listing changed. * **OwnerRez** - booking created, booking changed, payment received, refund issued. Webhook health is shown on the **Integration Status** panel under **Settings**. A red light means PX did not register or failed verification - click **Refresh** there to retry. If you ever suspect data is stale, click **Refresh** on the relevant page. Most pages have a refresh button at the top. ## Manual properties You can also create properties manually from the Properties page (**Add Manually**). Manual properties have no PMS ID, so: * They are never overwritten by a sync. * They do not appear in audits - audits read from PMS reservations only. * They are useful for tracking off-platform inventory in PX without distorting your PMS data. ## Switching PMSes PX supports one active PMS per account. Switching requires: 1. **Settings** -> remove the existing connection (**Delete** for Guesty, **Disconnect** for OwnerRez). 2. Connect the new provider. 3. **Properties** -> **Sync from \[new PMS]**. Removing a connection also removes the properties synced from it, so you will not see two providers' properties side by side. Your account-level configuration - business models, tax configuration, and audit history - stays in place, and step 3 repopulates the property list from the new PMS. # PMS integrations overview Source: https://docs.pxaccounting.com/integrations/overview Connect your PMS to PX Accounting and start auditing. PX Accounting connects to one PMS at a time. The connection lives on the **Settings** page, in the **Connect Your PMS** card. Pick yours below. Paste an integration token from the Guesty Marketplace. One-click OAuth. Personal Access Token. API key from Uplisting settings. Account ID and Secret Key. Agency-level API key. API key from Lodgify settings. ## What gets synced The first time you connect, PX pulls: * **Properties** - one record per listing, including name, address, thumbnail, capacity, and active/inactive flag. * **Owners** (when present in the PMS) - mapped to properties so you can see the owner inline on each property. Reservations and financial data are fetched **on demand** when you open a property's Reservations tab or run an audit. PX caches selectively to keep audits fast and stay under PMS rate limits. ## Webhooks PX registers webhooks with your PMS at connection time so changes (new bookings, cancellations, listing updates) flow in without waiting for a sync. You can verify webhook health on the **Integration Status** panel under Settings. ## What PX is not PX does **not** keep its own ledger or bookkeeping system. It reads your PMS data and audits it against your business model and tax configuration. Where your PMS exposes journal entries (some do, some do not), PX uses them. Where it does not, PX works from per-charge data to compute what the postings should look like for audit purposes only. ## Switching PMSes PX supports one active PMS per account. Switching providers requires deleting the existing credentials from **Settings** before connecting a new one. Historical data tied to the old PMS stays in place; new syncs populate against the new provider. ## Rate limits PX respects PMS rate limits. If you hit one (most common when running large audits), the UI shows a 429 banner with a countdown - the affected button stays disabled until the cooldown finishes. # Guesty PMS configuration Source: https://docs.pxaccounting.com/pms-configuration/guesty Read-only mirror of fees, taxes, and channel commissions configured in Guesty. The **PMS Configuration** page on Guesty accounts is a read-only window into how your PMS is set up. PX uses this configuration as the source of truth for audits. To change any of the settings shown here, change them in Guesty and click **Refresh from PMS**. Guesty PMS configuration ## Page structure Three lazy-loaded sections, each rendering its own card: 1. **Account Fees** 2. **Account Taxes** 3. **Channel Commissions** A **Refresh from PMS** button at the top of the page re-fetches all three sections from Guesty. An info banner sits below explaining the read-only nature. ## Account Fees Fees configured at the account level in Guesty - cleaning fee, pet fee, extra guest fee, and any custom fees you have added. Each fee row shows: * **Name** - the fee label. * **Default amount** - account-level default. Listings can override. * **Charge type** - `flat`, `per night`, `per guest above N`, or custom. * **Applies to** - which booking types or channels. This list mirrors the **Account Fees** section under your Guesty account settings. Adding or removing entries happens in Guesty. ## Account Taxes Tax rules at the account level. Each row shows: * **Name** - the tax label. * **Percent** - the rate. * **Applies to** - fee categories the tax applies to (`ACCOMMODATION_FARE`, `CLEANING_FEE`, etc.). * **Applies to channels** - OTA channels. * **Is inclusive** - whether the tax is priced into accommodation or added on top. * **Stay-length filter** - if applicable. This is the same data shown under **Tax Configuration** -> **Account-level**. The two pages duplicate intentionally - users tend to look for taxes under Tax Configuration and fees + commissions under PMS Configuration. ## Channel Commissions Per-channel commission rules from your Guesty channel configuration. Each row shows: * **Channel** - the channel name (Airbnb, Booking.com, Vrbo, etc.). * **Commission %** - the rate Guesty deducts. * **Commission basis** - what the commission is calculated on. * **Effective dates** - if Guesty has time-bound rates. PX uses these rates when validating commission lines on bookings during audits. If a Guesty booking on Airbnb has a 14% commission line but your channel configuration says 17%, the audit fires `COMMISSION_MISMATCH`. ## Per-listing config The page above shows account-level config. Listings may have **listing-level overrides** - those are visible from the **Property detail** -> **PMS Config** tab. The per-listing view has the same three sections (Account Fees, Account Taxes, Channel Commissions) but scoped to the specific listing. ## Refreshing Click **Refresh from PMS** at the top of the page to re-fetch all three sections from Guesty. PX: * Pulls fresh data via the Guesty admin API. * Updates its mirror in place. * Surfaces any errors in a banner at the top. Refreshing is safe - it does not change anything in Guesty. PX is read-only. ## Errors and rate limits Guesty has API rate limits. If you refresh too frequently, you may see a 429 response. PX backs off automatically and retries; meanwhile the page shows the cached version. If a refresh fails for another reason (expired credentials, deleted listing, etc.), the section header shows a red banner with the cause. Most issues resolve by reconnecting the PMS under Settings. ## Why this page exists PX shows you the same configuration Guesty has so you can answer the question "did the PMS apply this rule on this booking?" without bouncing between Guesty and PX. When an audit reports `COMMISSION_MISMATCH`, you can open this page and see whether the channel commission setting changed mid-period - a common cause. # OwnerRez Catalog Source: https://docs.pxaccounting.com/pms-configuration/ownerrez-catalog Build and confirm the audit baseline for OwnerRez accounts. For OwnerRez accounts, PX maintains the **OwnerRez Catalog** - a list of the tax, surcharge, and commission rules audits use as the baseline. Most rows are detected for you automatically from your booking history; you confirm or edit them. You configure the actual rates **in OwnerRez itself** (Settings -> Taxes, Settings -> Surcharges, Property Management -> Setup & Configuration). The catalog in PX is the audit's source of truth. OwnerRez Catalog ## How catalog entries are created Three ways: 1. **Inferred from booking history.** Click **Detect from bookings** and PX scans your last 18 months of bookings, looking for patterns in line items. Any rule that recurs is added as `inferred`. 2. **Manually added.** Click **Add row** to enter a tax, surcharge, or commission you know exists but PX did not pick up. 3. **Imported from OwnerRez** during the initial sync if catalog data is found in any payload PX can read. After detection, every row sits in `inferred` status until you review it. ## Statuses Each catalog row has a status: | Status | Used by audits? | Meaning | | ------------ | --------------- | ------------------------------------------ | | `inferred` | No | Auto-derived. Awaiting review. | | `user-added` | Yes | You created the row manually. | | `confirmed` | Yes | You reviewed and approved an inferred row. | | `archived` | No | Hidden from audits but kept for history. | To use a row in audits, it needs to be `user-added` or `confirmed`. Until you confirm at least one tax row, audits short-circuit with a `CATALOG_EMPTY` finding instead of running per-reservation checks. ## Detection options Click **Detect from bookings** to open the detection dialog: * **Lookback days** - how far back to scan. Default 60. * **Rebuild** - if checked, PX wipes existing inferred rules before re-deriving. Use this when your catalog has gone stale. For accounts with many listings (200+), detection runs as a background job. You will see a progress card on the **Home** page under **Accounting Diagnostic Job Runs**. For smaller accounts, detection runs inline and returns immediately. ## Row anatomy | Field | Meaning | | -------------- | ---------------------------------------------------------------------- | | **Kind** | `tax`, `fee`, or `commission`. | | **Name** | Display label. | | **Rate** | The numeric value. | | **Unit** | `percent` or `fixed`. | | **Applies to** | Categories the rule applies to (accommodation, cleaning, total, etc.). | | **Scope** | Account-wide or specific listings. | | **Status** | One of the four above. | | **Notes** | Free-text. Useful for jurisdiction notes. | You can edit any field on a `user-added` row. On `inferred` rows, editing a field auto-confirms the row. ## Scoping to listings A catalog row can be: * **Account-wide** - applies to every listing. * **Listing-scoped** - applies only to a specific subset. Use listing scope when a tax or fee is specific to a property (a city tax that only applies to a city-located listing, for example). The picker on the row lets you select multiple listings. If a row is account-wide, every listing-scoped row that overlaps with it takes precedence on its listings. ## Workflows ### After connecting OwnerRez for the first time 1. Open **PMS Configuration**. 2. Click **Detect from bookings** with default settings. 3. Review the resulting list. 4. **Confirm** rows that match your reality. 5. **Edit** rows where the inferred rate is close but not exact. 6. **Add** any tax or fee PX missed. 7. **Archive** rows that are no longer used. This usually takes 10-30 minutes for a typical PMC. ### After a tax rate change 1. Update the tax in OwnerRez. 2. Open the catalog in PX. 3. Edit the affected row, update the rate, and Save. 4. From that point on, audit findings on bookings will be evaluated against the new rate. ### When PX detects a new pattern PX may surface new `inferred` rows after future runs of **Detect from bookings**. Review them and confirm or archive as appropriate. Confirmed rows stay confirmed; inferred rows are recreated each time you re-detect. ## Audit interaction The audit consults the catalog as its baseline: * **Tax findings** check the booking's tax lines against the tax rows in the catalog scoped to that listing. * **Fee findings** check fees against the fee rows. * **Commission findings** check commission lines against the commission rows. * A **CATALOG\_EMPTY** finding is emitted if the catalog has no confirmed rows of the relevant kind, so the audit short-circuits instead of running misleading checks. Each finding points back to the specific catalog row that drove the expectation, so you can edit the row and re-run the audit to see if the finding clears. ## Where on this page does each item live in OwnerRez? | In PX | In OwnerRez | | ------------------------------ | -------------------------------------------- | | Tax rows | Settings -> Taxes | | Fee rows (cleaning, pet, etc.) | Settings -> Surcharges | | Commission rows | Property Management -> Setup & Configuration | PX is opinionated about catalog structure to keep audits sane. If your OwnerRez setup uses unusual constructs (custom calculated fees, conditional surcharges), enter them as best you can and use the **Notes** field to document edge cases. # Auto-fix Source: https://docs.pxaccounting.com/properties/auto-fix How auto-fix resolves issues automatically and when to leave it off. Auto-fix is PX's automatic resolution of safe-to-fix findings. When it is on for a property, PX moves unresolved findings into a queue and resolves them in the background. ## Where the toggles live * **Per-property** - the **Auto-Fix** column in the Properties table, and the toggle on the property detail page header. * **Globally** - the **Auto-fix all** toggle in the Properties table card header. Flipping this updates every property in your account at once. The two layers are stored together: flipping global on sets every property to on. Flipping global off does the same in reverse. After that, you can fine-tune per-property. ## What changes when auto-fix is on On the property detail Overview tab: * Unresolved findings show a **Fix in Progress** badge. * The **Start Fix** and **Dismiss** buttons are not shown. * The help text reads: *"Auto-fix is enabled. Issues will be processed automatically."* On the Properties table: * The **In Progress** column shows the count of findings PX is processing for that property. * The **Auto-Fix** column shows the toggle in its on state. ## What auto-fix actually does Auto-fix resolves findings that are deterministic and safe - the kind of issue with a single correct outcome. Examples include: * Marking a clearly fixed issue as resolved when a follow-up reservation update made it whole. * Closing duplicate findings that point to the same underlying issue. * Re-running checks after a PMS configuration change to clear obsolete findings. When a finding requires a change in your PMS to actually be fixed (a missing tax line, a wrong commission rate on a booking, etc.), PX coordinates the change directly with your PMS on your behalf and then updates the finding status once the change is confirmed. ## When to leave auto-fix off Leave it off if: * You are still onboarding and want a human to review each finding the first time around. * You are running a one-time clean-up across historical bookings and want to triage manually. * You want a per-finding audit trail that shows every Start Fix or Dismiss action. You can always start with auto-fix off, work through findings manually for a couple of weeks, and flip it on once the cadence is comfortable. ## Manual flow (auto-fix off) For each unresolved finding on the property detail Overview tab: * Click **Start Fix** to mark it in progress. PX records the timestamp and (where applicable) the fix details. * Click **Dismiss** to close the finding without fixing. Use this for false positives or bookings outside the audit scope. Both actions are reversible - opening the issue and toggling status updates the audit log. ## Visibility Open the **Home** dashboard to see an aggregate view of how auto-fix is doing across the portfolio: * **Issues by Status** - donut chart of unresolved / in progress / fixed / dismissed. * **Issues Trend (14 days)** - detected vs fixed lines over time. * **Properties Needing Attention** - listings with the most unresolved findings. # Manage properties Source: https://docs.pxaccounting.com/properties/manage Browse your portfolio, search and filter, toggle auto-fix, and trigger a sync. The **Properties** page is your portfolio at a glance and the entry point for drilling into a single listing. Properties page ## Header actions * **Add Manually** - opens a form to create a property that is not in your PMS. Useful for off-platform inventory you want tracked in PX. * **Sync from \[PMS]** - triggers a full re-fetch of your listings. The button label changes to match your active provider. ## The table | Column | What it shows | | ----------------- | ------------------------------------------------------------------------------- | | Name | Property name with thumbnail. Sortable. Click to open the property detail page. | | Type | The PMS property type (apartment, house, etc.). | | Base Nightly Rate | Guesty only - hidden for OwnerRez accounts. | | Status | Active or Inactive. | | Business Model | The business model assigned to this property (or empty). | | Unresolved | Count of unresolved findings. Sortable. | | In Progress | Count of findings currently being auto-fixed. Sortable. | | Auto-Fix | Per-property toggle. | Above the table: * **Search properties...** - filters the table by property name in real time. * **Page size** dropdown - 25 / 50 / 100 / 200 per page. Defaults to 50. * **Auto-fix all** toggle in the card header - flips auto-fix on or off for every property at once. Pagination controls (**Previous**, **Next**, **Page X of Y**) appear at the bottom. ## First-time experience If you just connected a PMS and have not synced yet, the page is empty and PX automatically triggers a sync in the background. You will see a loading state, then the table populates. If you have not configured PMS credentials, the empty state prompts: **Configure your PMS credentials in Settings, then sync.** ## Auto-fix toggles There are two layers: * **Per property** - the toggle on each row, which is the default control. * **Globally** - the **Auto-fix all** toggle in the header. Flipping this updates every property at once. When auto-fix is on for a property: * Unresolved findings on that property show **Fix in Progress** instead of the **Start Fix** / **Dismiss** buttons. * PX processes the fixes asynchronously - you do not have to wait on the page. When auto-fix is off: * Findings stay unresolved until you act on them from the property detail page. See [Auto-fix](/properties/auto-fix) for the full behavior. ## Triggering a sync Click **Sync from \[PMS]** to re-fetch your listings. Sync is idempotent - running it twice is safe and only updates rows where data changed. If a sync fails, an error banner appears at the top of the page with the reason. The most common causes are: * Expired credentials (re-connect under Settings). * PMS rate limit hit (wait, then retry). * A specific listing failed to parse - PX skips it and continues; the rest still sync. ## What's next Issues, reservations, and PMS config for a single listing. What auto-fix does and when to use it. # Property owners Source: https://docs.pxaccounting.com/properties/owners How owner records sync from your PMS and where they show up in PX. PX shows owner information **inline on each property**. There is no separate Owners page and no manual sync button - owners come from your PMS automatically. Property detail with owner info ## Where you see owner info * **Property detail page** - the Owner card sits below the property info grid, showing the owner's name, email, and phone. * **Reservations** - business model assignments and statement reconciliation use the owner mapping. ## How owner sync works PX pulls owner records from your PMS during the regular property sync, then maps them to properties through a join table. You do not have to do anything to trigger this - syncing properties syncs the related owners too. The mapping is stored in PX, so even if a property's PMS record loses its owner reference temporarily, PX preserves the last-seen mapping until the next successful sync. ## What if my property has no owner? Some properties (your own listings, manually added entries) have no owner mapping. PX simply hides the Owner card on those properties - no error, no warning. If a property *should* have an owner but does not show one: 1. Confirm the owner is associated with the listing in your PMS. 2. Click **Sync from \[PMS]** on the Properties page. 3. Open the property and refresh. The Owner card should appear. ## Multiple owners If your PMS records multiple owners on a single property, PX displays the primary owner as identified by the PMS. ## Privacy Owner contact details (email, phone) are visible to anyone with access to your PX account. Use account-level access controls and Single Sign-On to restrict who can see them. # Property detail Source: https://docs.pxaccounting.com/properties/property-detail Issues, reservations, and PMS config for a single property. Click any row in the Properties table to open the property detail page. The page has three tabs: **Overview**, **Reservations**, and **PMS Config**. Property detail ## Header The top of the page shows: * A back button to the Properties list. * The property thumbnail, name, status badge, and business model badge. * The full address. * The per-property **Auto-Fix** toggle. Below the header is a grid of property info cards: **Type**, **Bedrooms**, **Bathrooms**, **Guests**, **Base Nightly Rate** (Guesty only), and **Cleaning Fee** (Guesty only). If the property has an owner mapped in your PMS, an **Owner** card shows the owner's name, email, and phone inline. There is no separate Owners page - owner info lives here. See [Property owners](/properties/owners). ## Overview tab The Overview tab is the primary view for issue management. **KPI cards:** * **Unresolved** - findings not yet acted on. * **Fix in Progress** - auto-fix is processing these. * **Total Issues (All Time)**. * **Fixed (All Time)**. **Issue filter dropdown** - narrows the issue list by type: * All Issue Types (default) * Missing Payment * Overcharge * Records Don't Balance * Deposit Not Cleared * Wrong Entry Date * Deposit Mismatch * Missing Deposit Records **Issue list** - one row per finding, expandable for detail: * Severity badge (error / warning / info). * Status badge (unresolved / in progress / fixed / dismissed). * Issue type label. * One-line description. * Detected date and (if applicable) fixed date. **Action buttons** depend on auto-fix state: * **Auto-fix off + unresolved** - **Start Fix** and **Dismiss** buttons appear. * **Auto-fix on + unresolved** - **Fix in Progress** badge replaces the buttons. * **Fixed or dismissed** - icon only. Help text above the list reflects the auto-fix state: * *"Auto-fix is enabled. Issues will be processed automatically."* * *"Review and manage detected issues. Showing issues from the last 90 days."* ## Reservations tab Browse this property's reservations and click any row to open the accounting folio. **Filters (three dropdowns):** * Look-back range: **Last 30 days** / **Last 90 days** / **Last 180 days**. * Look-forward range: **Next 0 days** / **Next 30 days** / **Next 90 days**. * Status: **All** / **Confirmed** / **Reserved** / **Checked-In** / **Checked-Out** / **Canceled** / **Pending** / **Inquiry**. **Refresh** button on the right re-fetches reservations from the PMS. **Each reservation row shows:** * Confirmation code (monospace). * Status badge. * **Paid** badge if fully paid. * **Balance Due** badge if a balance remains. * Guest name, dates, nights, channel, business model. * Host payout (primary number). * Gross total (shown if it differs from host payout). Click a reservation to open the **Folio modal**, which shows the accounting detail: * On Guesty - journal entries from Guesty's accounting engine. * On OwnerRez - charges + payments + refunds + deposits assembled into a folio. ## PMS Config tab Read-only view of how this listing is configured in your PMS. **On OwnerRez:** * The OwnerRez Catalog renders, filtered to entries scoped to this listing. * You can confirm or edit catalog rows here without leaving the property. **On Guesty:** * A **Refresh** button at the top. * Three lazy-loaded sections: * **Account Fees** - account-level fees that may apply to this listing. * **Account Taxes** - account-level tax rules. * **Channel Commissions** - per-channel commission rules from your Guesty config. * Help text: *"Read-only fees, taxes, and channel commissions configured in your PMS for this listing."* If Guesty fails to return config, an error banner explains why (most often: scope or temporary API outage). ## What's next Per-property and global behavior. Use the listing filter on the Audits page to scope to this property. # Account-level taxes Source: https://docs.pxaccounting.com/tax-configuration/account-level Read-only view of taxes that apply to every property in your PMS account. The **Account-level** tab on the Tax Configuration page shows taxes configured at the account level in your PMS. These are the taxes that apply to every property unless a listing-level override exists. This view is **read-only**. To change a rate or applicability rule, change it in your PMS and then click **Refresh from PMS** in PX. Account-level taxes ## Per-PMS behavior ### Guesty * The Account-level tab shows the **Account Taxes** section with one row per tax. * Each row reports name, percent, applicability rules, and is\_inclusive flag. * Help text: *"Read-only view of taxes configured in your PMS."* * Click **Refresh from PMS** at the top of the page to re-fetch. ### OwnerRez * The Account-level tab renders the **OwnerRez Catalog** filtered to `kind = tax`. * Tax rates are **inferred** from booking history and confirmed by you. * See [OwnerRez Catalog](/pms-configuration/ownerrez-catalog) for details on the catalog UI. ## What each field means | Field | Meaning | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Display label for the tax (`Lodging Tax 8%`, `City Hotel Tax`, `VAT`, etc.). | | **Percent** | The tax rate. | | **Applies to** | Categories the tax applies to (`ACCOMMODATION_FARE`, `CLEANING_FEE`, custom fees). Empty list means accommodation only. | | **Applies to channels** | OTA channels where this tax syncs. Defined in your PMS. | | **Is inclusive** | If true, the tax is priced into the accommodation rate (the guest sees the tax-inclusive price). If false, the tax is added on top. | | **Stay-length filter** | Some taxes only apply to short stays (\< 30 nights). Configured in your PMS. | PX displays these fields when your PMS exposes them. Guesty exposes most; OwnerRez exposes them only when you have entered them into the catalog. ## The "applies to" list The most common configuration is: * **Lodging tax** - applies to `ACCOMMODATION_FARE` only. * **Sales tax** - applies to `ACCOMMODATION_FARE` and `CLEANING_FEE`. * **Resort fee tax** - applies to `RESORT_FEE`. Empty `applies_to` means the tax applies to accommodation only (not to fees). ## Listings inheriting vs overriding The Account-level tab shows the account defaults. Some listings may have **listing-level overrides** that take precedence. Those are listed under the Per-listing tab, grouped by inheritance state. See [Per-listing taxes](/tax-configuration/per-listing) for the listing-level view. ## Validation warnings PX surfaces a few warnings if it detects PMS configuration patterns that commonly cause issues: * **Booking.com tax compatibility** - Booking.com only supports certain tax structures, and Guesty's UI does not always enforce that. PX warns when a tax is configured in a way that Booking.com will not honor. * **Inclusive vs exclusive ambiguity** - if multiple taxes apply to the same fee with mixed inclusivity, PX flags it because the math is brittle. Warnings appear inline next to the affected row. ## Refreshing Click **Refresh from PMS** at the top of the page to re-fetch the latest tax configuration. PX updates its mirror in place. If a refresh fails, you will see an error banner with the cause - most often a transient PMS rate limit or an expired credential. # Airbnb tax remittance Source: https://docs.pxaccounting.com/tax-configuration/airbnb-remittance Tell PX which taxes Airbnb collects and remits so audits suppress those findings. Airbnb collects and remits some taxes on behalf of hosts in many jurisdictions. When that happens, your PMS may or may not record those taxes on the booking - and if you do not tell PX about it, audits will flag them as `MISSING_TAX` findings. The **Airbnb Tax Remittance** card sits at the top of the Tax Configuration page, subtitled *Tell us how Airbnb handles taxes for your properties*. It asks up to three questions, each revealed once you answer the one above it. The setting is stored in PX only. PX does not push it back to your PMS or to Airbnb. It exists purely to inform PX's audit logic. Airbnb remittance card The card expands automatically while nothing is saved, and collapses to a one-line summary afterwards. Before you configure it the summary reads *Not configured yet*; once saved it reports what you chose, for example *Airbnb remits taxes for 12 properties across 3 groups*. ## Does Airbnb collect and remit any taxes for you? * **Yes** - *Airbnb handles some or all tax payments*. Answering Yes reveals the next question. * **No** - *I pay all taxes myself*. Audits then expect every tax on every Airbnb booking, and there is nothing else to configure. If Airbnb remits at least one tax on at least one of your listings, answer **Yes**. ## Does Airbnb handle tax remittance the same way for all your properties? * **Yes, same for all** - *I'll choose which taxes once, applies to every property*. * **No, it differs by property** - *I'll set up groups of properties with different tax remittance*. Choose **No** when remittance is jurisdiction-specific. For example, Airbnb remits Texas state hotel tax on your Texas listings but not on your California listings. ## Which taxes does Airbnb remit? This question only appears on the **same for all** path: * **All guest taxes** - *Every tax charged to guests*. Audits skip every tax check on Airbnb bookings. * **Only specific taxes** - *I'll choose which ones*. Opens a checklist of every tax PX has on file, so you can tick the ones Airbnb remits. The quick path is three clicks: **Yes**, then **Yes, same for all**, then **All guest taxes**, then **Save**. ## Property groups On the **differs by property** path, the card switches to **Set up your property groups**. Click **Add a property group** (then **Add another property group**) to build as many as you need. Each group holds a set of properties and its own tax choice: | Group tax mode | Effect | | ----------------------- | -------------------------------------------------- | | **All taxes** | Airbnb remits everything for these properties. | | **Only specific taxes** | Pick which taxes from the checklist. | | **No taxes** | Airbnb collects but remits nothing for this group. | A property belongs to **at most one** group. The property picker greys out anything already assigned and tells you how many, for example *3 already in other groups*, so you cannot double-assign by accident. Properties you never assign to a group are not covered. The card warns you with *`` properties not covered* and explains that Airbnb will not remit taxes for them. Add them to a group, or create a new one, before saving. ## Custom taxes Airbnb sometimes remits a tax that does not exist as a separate line in your PMS catalog. Inside the **Only specific taxes** checklist, **Add a custom tax** records those with a **name** and a **rate**. Custom taxes appear in their own **Custom taxes** section of the checklist, where you can edit or delete them. They are stored only on the remittance record and do not appear in your account-level taxes. They exist purely so PX knows to expect them on Airbnb bookings and does not flag an `UNEXPECTED_TAX`. ## Saving The footer shows **Not saved yet** until the first save, then *Last saved* with the date and time. * **Save** - stays disabled until the configuration is valid. * **Discard** - appears only while you have unsaved changes, and returns the card to the last saved state. * **Reset to default** - clears the configuration back to unconfigured. If something is incomplete, a hint appears above the buttons instead of a silent failure. The two you are most likely to see: * *No properties selected yet - add at least one property to a group before saving.* * *`` empty groups will be removed on save.* ## How an audit applies remittance For each Airbnb booking: 1. Is there a remittance record for this account? If not, audit normally. 2. Does this booking's listing fall under the remittance scope (all properties, or a group it belongs to)? 3. For each tax PX would normally check, is that tax in the remitted list? If yes, **skip** the check on this booking. 4. Treat each custom tax as expected on the booking, so PX no longer flags an `UNEXPECTED_TAX` for it. ## Common setups **Single jurisdiction, full remittance.** Yes / Yes, same for all / All guest taxes. The simplest setup, and the one most single-market operators want. **Multi-state operator.** Yes / No, it differs by property / one group per state, each with its own tax selection. **Hybrid.** Yes / Yes, same for all / Only specific taxes. Airbnb remits state lodging tax everywhere, but city-level taxes remain your responsibility. ## When to update it Update the card whenever: * A new state or county is added where Airbnb remits. * Airbnb changes its remittance behavior. This happens occasionally, so watch for sudden spikes in `MISSING_TAX` findings on Airbnb bookings. * You add a listing in a new jurisdiction. * A tax that used to be remitted becomes your responsibility, or the reverse. There is no re-run requirement. The next audit picks up the new configuration automatically. ## Validation rules * Each property can appear in **at most one** group. * Custom taxes need both a name and a rate. Empty values are rejected. * Empty groups are dropped when you save. * There is one Airbnb remittance record per account, so saving always replaces the previous configuration. # Channel sync overrides Source: https://docs.pxaccounting.com/tax-configuration/channel-overrides Tell PX which channels a tax syncs to so audits stop flagging false positives. Channel sync overrides are PX's user-writable layer for "is this tax expected to appear on a booking from this channel?" They live on the Tax Configuration **Per-listing** tab, embedded next to each tax row. Channel sync overrides are stored **inside PX only**. They tell PX what to expect during audits. PX does not push them back to your PMS. ## Why they exist PX cannot always tell from PMS data alone which channels actually carry which taxes. Channel sync overrides are a writable layer where you state your reality: > "Lodging tax syncs to direct and Vrbo bookings, but not to Airbnb (because Airbnb collects it) and not to Booking.com (because Booking.com cannot pass through this rate)." When an audit runs against a booking, PX consults this layer to decide whether to expect the tax in the recorded charges. This is the difference between a clean audit and a wall of `MISSING_TAX` findings. ## Two scopes A channel override is scoped at one of two levels: * **Account scope** - applies to every listing in your account. * **Listing scope** - applies to one specific listing. Overrides the account scope for that listing. If both exist for the same tax, the listing scope wins. ## How to set an override 1. Open **Tax Configuration**. 2. Switch to the **Per-listing** tab. 3. Click a listing to open its detail view. 4. Each tax row has a strip of **channel chips** - one per channel. 5. Click a chip to toggle whether the tax syncs to that channel. Saving is **automatic** - PX persists the change as soon as you click. There is no Save button to forget. Per-listing groups To set an account-scope override (apply to every listing), use the same toggles on a representative listing, but choose the "Apply to account" option in the dialog when prompted. PX records the change at account scope. ## Common channel slugs | Slug | Channel | | ------------ | ----------------- | | `airbnb2` | Airbnb | | `bookingCom` | Booking.com | | `vrbo` | Vrbo | | `expedia` | Expedia | | `direct` | Direct booking | | `homeAway` | HomeAway (legacy) | If your PMS uses a slug PX does not recognize, the chip still appears with the raw slug name. Toggling it works the same way. ## How an audit consults overrides For each tax on each booking, the audit decision tree is: 1. Is there a **listing-scope** override for this tax? * If yes, use it. The listed channels are expected; others are not. 2. Otherwise, is there an **account-scope** override? * If yes, use it. 3. Otherwise, fall back to the PMS's `applies_to_channels` field. 4. If still ambiguous, default to "applies to all channels" and report differences as findings. ## When NOT to use channel overrides Channel overrides are about **expected sync**, not about marketplace remittance. If Airbnb collects and remits a tax on your behalf, that is a separate setting: * Use [Airbnb tax remittance](/tax-configuration/airbnb-remittance) for marketplace-collected taxes. PX excludes them from findings on Airbnb bookings. * Use channel overrides for "this channel does not have this tax in its system at all." Both can apply to the same tax. For a state lodging tax that Airbnb remits in some states and not others, you might use Airbnb remittance to exclude the tax on properties in remitted states, and a channel override to exclude it on listings sold via a channel that does not pass it through. ## Resetting To remove an override: 1. Toggle the chips back to their default state. 2. PX deletes the override row when no chips remain modified. You can also delete an override programmatically, but the UI toggle is the supported path. # Tax configuration overview Source: https://docs.pxaccounting.com/tax-configuration/overview The three layers of tax configuration in PX and how audits use them. Tax configuration in PX has three independent layers. Knowing which layer to touch is the difference between a five-minute change and an afternoon of debugging. ## The three layers Read-only view of taxes from your PMS. Change them in your PMS, not in PX. PX-only. Per-tax, per-channel toggles for which channels a tax syncs to. Stored in PX, not pushed to your PMS. PX-only. Tells PX which taxes Airbnb collects and remits, so audits exclude them. Stored in PX, not pushed to your PMS. The two writable layers (channel sync overrides and Airbnb tax remittance) are stored **inside PX only**. PX never writes back to your PMS. If you need to change a rate or applicability rule, change it in your PMS. ## Why three layers? Real-world tax setups need all three: 1. **The rates and applicability** - the lodging tax is 9.5%, applies to accommodation only, applies to stays under 30 nights. This lives in your PMS. 2. **Sync behavior per channel** - the same tax may sync to your direct channel but not to Booking.com because Booking.com cannot pass through the rate. PX provides a channel override layer you maintain inside PX so audits know what to expect on each booking. 3. **Marketplace remittance** - Airbnb collects and remits some taxes on your behalf in many jurisdictions. Audits should not flag those taxes as missing on Airbnb bookings. PX combines all three to decide what to expect on a given booking. ## How an audit uses tax configuration For each reservation: 1. Look up the property's PMS taxes (account-level + listing-level overrides). 2. For each tax, check **channel sync overrides** - does this tax sync to this booking's channel? 3. If the channel is Airbnb, check **Airbnb remittance** - does Airbnb remit this tax? 4. If the tax is expected, compare the recorded amount on the booking to the calculated amount. 5. Emit a finding when expected and actual diverge. Each finding labels which layer drove the expectation. ## Where to start If you are just connecting your PMS: 1. Open **Tax Configuration**. 2. Refresh the PMS mirror so the latest rates are loaded. 3. Confirm the taxes look right. 4. Walk through the **Airbnb tax remittance wizard** if it is shown for your PMS. 5. Add channel sync overrides for any tax that should not flow to a given channel. The exact buttons, what gets refreshed, and whether the Airbnb remittance wizard appears all depend on which PMS is connected. See your PMS's **Connect** page for the specifics. You can run audits without doing any of this, but you will see a lot of `MISSING_TAX` and `UNEXPECTED_TAX` findings until tax configuration matches reality. # Per-listing taxes Source: https://docs.pxaccounting.com/tax-configuration/per-listing How listing-level overrides work and how to find them quickly. The **Per-listing** tab on the Tax Configuration page shows your listings grouped by how they relate to the account-level tax configuration. ## Group view When you open the tab, listings are grouped into sections. Click any listing to drill in. ### Guesty groups * **Inheriting account-level tax configuration** - the listing uses the taxes you see on the Account-level tab. No special handling. * **Listing-level override (custom)** - the listing has a tax setup that differs from the account default. Most common when a property is in a different tax jurisdiction. * **Unknown inheritance state** - PX could not determine inheritance from the PMS response. Usually rare and resolves on the next refresh. ### OwnerRez groups * **Properties with confirmed taxes** - the OwnerRez catalog has confirmed tax entries scoped to (or applicable to) this listing. * **Properties without configured taxes** - no confirmed catalog entries match this listing. Audits on these listings will likely return `CATALOG_EMPTY` or skip tax checks. A search box at the top filters the listing list by name in real time. Per-listing groups ## Drill-down view Click a listing to open its detail. The detail page shows: * A **Back** button to return to the group view. * The listing name as title. * Help text: *"Read-only tax configuration reported by the PMS for this listing."* * A banner indicating inheritance state: * **Blue** for listings inheriting from account level: *"This listing currently inherits its taxes from the account level."* * **Amber** for listings with overrides: *"This listing has a listing-level override in the PMS."* * The taxes that apply, with channel override chips next to each tax (editable). ### OwnerRez per-listing For OwnerRez, the listing detail renders the **OwnerRez Catalog** scoped to entries that apply to this listing. You can confirm or edit catalog rows directly. ## Editing channel overrides per-listing Each tax row has channel chips - these are PX's [channel sync overrides](/tax-configuration/channel-overrides). Click a chip to toggle whether the tax syncs to that channel for this listing. Saving is automatic - PX persists the change as soon as you toggle. There is no Save button. ## When a listing has a custom tax If a listing has a listing-level override in your PMS, the override takes precedence over the account default. PX shows the listing-specific taxes in the drill-down; the account taxes do not apply. To make a listing follow the account default again, remove the override in your PMS, then click **Refresh from PMS** in PX. ## What about listings I added manually? Manually-added properties in PX do not have PMS-side tax configuration. They appear under "Properties without configured taxes" on OwnerRez. Audits skip tax checks for manual properties.