Razor

Help with your company payments

Find the steps for the product you are using. Supported assets and configured providers depend on current availability. Your account and company permissions still apply.

12 guides. Company links use your signed-in workspace and its current permissions.

Getting started

Start a company and invite your team

Create a workspace before funding it, then separate sign-in from treasury authority.

Start working

  1. Sign in with a supported wallet, or Google/email when configured by the operator. A connected wallet alone does not prove ownership; complete the sign-in challenge.
  2. Create your company, set its timezone and review the roles you give teammates. A company invitation grants only its assigned permissions.
  3. Prepare payees, payroll and bills before funding. Link and verify your NEAR owner wallet when activating the shared company treasury. Social sign-in does not replace financial authority.

Funding and assets

Fund with one or several supported assets

Use current catalog assets, exact deposit instructions and independently verified USDC credit.

Fund deliberately

  1. Open Treasury and select the exact asset and network from the live catalog. You may use more than one funding leg. Native USDC suggestions are optional compatibility guidance; a current quote determines actual cost.
  2. Review the wallet account, source network, amount, refund address, gas and deposit instructions before signing. Use the saved funding task or original funding link to resume a transfer.
  3. A submitted hash or provider success is not spendable company cash. Razor requires its final canonical NEAR USDC credit and company binding. Testnet tokens do not establish mainnet funding.
  4. If the wallet was interrupted or a result is unknown, track the original source transfer. Do not create a replacement deposit until the original outcome is resolved.

Payroll and recipients

Confirm your receiving asset and USDC backup

Employees, contractors and suppliers control their own verified receiving choices.

Choose a destination

  1. Open your personal receiving workspace and confirm the exact primary asset, network and address. Use an asset currently supported by the live catalog.
  2. Your backup is native USDC on an enabled supported network. Review its separate address and explicitly consent to fallback. An EVM address does not identify its network.
  3. Read compatibility suggestions, supported destination metadata and receiving-wallet restrictions. Do not use a custodial deposit address that requires unsupported metadata.
  4. A profile change is versioned. It cannot silently redirect an existing liability, expose an old recipient's history or approve a changed payment.

Payroll and recipients

Prepare payroll, approve routes and check actual payment

Review exact amounts, imports, due dates and per-recipient outcomes.

Run payroll

  1. Create a pay run or upload the supported CSV. Review locale, column mapping, confirmed recipients, base pay, bonuses, signed adjustments and per-person cost ceilings before saving.
  2. Company liabilities are recorded in USDC. An employee may independently receive a supported primary asset. A cost ceiling is a budget, not an actual fee already charged.
  3. Review funding needs, obligation approvals and exact payout routes. A recurring calendar creates drafts; it does not automatically approve new salaries or extend a short-lived quote.
  4. Check every recipient's recorded outcome. A partial delivery leaves a remaining liability. Unknown transfers stay held; a separately approved remainder must preserve the original history.

Invoices and suppliers

Review invoices and supplier payments

Human agreement and ordinary bill approval remain separate from extraction.

Review the obligation

  1. Create a bill manually or use the configured invoice intake. Treat document amounts, payment instructions and AI extraction as observations that need review.
  2. Choose a separately confirmed payee and explicitly agree the USDC obligation. A printed foreign-currency amount is not an approved conversion.
  3. Check the supplier reference, duplicate warnings, due date, milestones, installments and disputes. Record receipt or acceptance where required before release.
  4. Approval creates no proof of settlement. Review the exact route, actual delivery and any remaining principal in Bills and Payments.

Private invoice processing

Process an invoice on your own computer

Keep original documents and your NEAR AI key outside Razor's hosted application.

Company-operated processing

  1. Use the reviewed source and installed dependencies with Node.js 24.22.1 or later. Configure your own NEAR AI key, model and independently approved gateway/model measurements on that computer.
  2. Run: node --max-old-space-size=512 --import tsx scripts/process-invoice-private.ts --input /absolute/invoice.pdf --output /absolute/review.json. Choose distinct absolute paths and a new output file. The command requires verification and has no Razor endpoint or hosted fallback. PDF processing also needs the local Linux tools.
  3. Input is bounded to 3 MB and supports UTF-8 TXT, PDF, PNG and JPEG. The review JSON contains sensitive plaintext extracted fields. New output files use mode 0600 and do not overwrite an existing file.
  4. Optional evidence includes encrypted wire bytes by default, or redacted metadata with --packet-mode metadata. It contains no decryption keys and does not authenticate separately supplied plaintext fields.
  5. Open the review file locally in the Assistant's company-operated panel. Only explicitly reviewed fields become an unapproved bill. Raw documents, full extraction, payment instructions, keys and evidence packets are excluded from that import.
  6. Delete your local source, environment files and exports when appropriate, and revoke your key in your NEAR AI account. Razor deletion cannot revoke downloaded copies. Local fixtures do not establish successful live hardware verification.

Provider setup

Understand provider setup and unavailable features

Distinguish missing credentials from a completed live connection.

Check the correct service

  1. Google/email sign-in requires matching Privy operator configuration. Wallet sign-in and NEAR financial approvals remain separate.
  2. Hosted private extraction requires the operator's NEAR AI model, key and approved measurements. Verification failure must stop inference; it is not a reason to send your document to another provider.
  3. Email is optional and requires a configured transport, verified identity and opt-in. Provider acceptance does not prove arrival.
  4. Missing provider configuration should show setup required. Report the feature name and fixed error code without sending client secrets, private keys, raw payroll or invoice files.

Provider setup

Connect QuickBooks Online or Xero

Authorize your legal entity and approve exact bookkeeping plans.

Connect and review

  1. The operator configures its confidential provider app and callback URLs first. Begin consent in Accounting with your current finance permissions and finish in the same browser within ten minutes. Logging out or changing the initiating session invalidates the pending request.
  2. After consent, explicitly select the verified legal entity. Load actual contacts, expense and clearing accounts and zero-tax codes. Supported writes are reviewed business bills and verified full-principal installment accounting payments.
  3. Approve a functional-currency FX numerator/denominator, source and date. USDC parity is never assumed. Fractional functional cents are held. Original invoice maturity uses the company timezone and stays separate from the posting date; unscheduled invoices require an explicit reviewed due date.
  4. Preparing a plan sends no financial write. Approve the exact plan, then process it or allow the configured worker to process an already approved request. Accounting does not transfer bank funds or establish cash credit.
  5. An uncertain write requires read-only reconciliation against its existing marker. Missing provider results never authorize blind resubmission. External edits enter conflict review. Disconnect stops future local work; confirm provider revocation separately.
  6. Automatic bank matching, NetSuite, payroll-row exports and fee/FX/credit-note journals remain unsupported. Local connector fixtures do not establish live provider acceptance.

Recovery and held transfers

Recover a delayed, failed or unknown transfer

Track the original attempt before considering a backup or remainder.

Protect the original history

  1. Open the exact payment or funding task and read its saved status. Keep the original public transaction hash, network and case reference. A timeout or an unknown wallet result does not prove failure.
  2. Use the provided source receipt, retained withdrawal or refund recovery controls with their required signer and verified original evidence. A support message is never refund authority or settlement proof.
  3. Backup payout requires the recipient's explicit consent and actual route eligibility. Partial delivery retains the delivered amount and remaining liability; a new remainder needs its own review.
  4. Do not send a duplicate transfer to test recovery. If you need help, sign in and record a private support case with a concise description. Do not include private keys, recovery phrases, API secrets or raw documents.

Other help

Record and track a private support case

A saved case is an intake record, not a promise of a staff response.

What to send

  1. Sign in to record a concise issue, what you expected, what happened and a fixed error code if one is visible. There are no attachments. Never paste credentials, recovery phrases or raw payroll/invoice documents.
  2. Optional company, payment and funding references are accepted only when your current account is authorized for that context. Knowing an ID or a public funding link does not grant access.
  3. Cases and replies are private to the sender and explicitly authorized support operators. Associating a company does not share a case with coworkers. Provider and payment references provide context only; they cannot approve spending, refunds or settlement.
  4. Read replies and status in your signed-in inbox. Recording a case does not establish staff availability, a paid support tier, an SLA or an outbound email notification.
  5. Text and context expire after the displayed retention date. You can delete them sooner; a minimal case and replay-protection record remains. Deleting a support case does not delete company payment records.

Invoices and suppliers

Use cash-backed company clearing

Settle accepted company invoices through native-USDC escrow with fixed owner-wallet credit and refund rights.

Review the separate money path

  1. Open Business clearing and opt in with the company's verified NEAR owner. Only accepted company business invoices can enter; employee wages and personal contractor payments stay in ordinary payment workflows.
  2. Every company reviews the exact invoice commitments, original net debit or credit, fixed owner destination and funding deadline. A fully balanced cycle can use debt-discharge clearing without cash escrow.
  3. An entirely unsigned local cash proposal can be discarded for free. Once registration signing starts, keep its exact identity and reconcile or revoke it onchain. Missing chain state does not release an uncertain action.
  4. Debtors fund native USDC directly from their frozen owner wallet after every company consents. Review the clearing registration storage, token registration where needed, exact deposit and NEAR gas before signing. Partial deposits remain visible; overpayment returns through the token resolver.
  5. Finalization needs every consent and exact full funding. It retires the agreed invoices into separate escrow-backed company rights, with no residual payment draft. These records remain separate from delivered payroll, shared treasury cash and earned receipts.
  6. Creditors withdraw only to the fixed consented owner wallet. Revoked or expired unfinished rounds preserve accepted-deposit refund rights. Pending withdrawals keep their original nonce; refresh the same outcome. A missing callback remains held, and no timeout or support message authorizes another payment.

Payroll and recipients

Create an optional native-USDC distribution

Use a separate claim pool for grants and distributions while ordinary payroll remains a push payment.

Fix the entitlement before funding

  1. Open Distributions and choose currently confirmed native NEAR USDC receiving profiles. Fix each entitlement, the total, a reference and a deadline. An unfunded draft can be cancelled without a transaction.
  2. The owner and highest configured approval quorum authorize the exact allocation commitment. Review company cash, prepaid storage and native NEAR signing costs. Unknown creation keeps cash reserved until authoritative reconciliation or onchain cancellation.
  3. Recipients use their personal receiving workspace to inspect only their own allocation. The signing wallet pays claim gas, and the receiving account may need a separate token storage registration. No automatic claim subsidy is provided.
  4. A retry can only use the same fixed claim identity, amount and destination. Pending or paid claims cannot pay twice. Failed token callbacks restore only the original claim liability.
  5. After the deadline, only genuinely unclaimed funds can return to company cash; pending transfers stay protected. Allocation accounts and amounts are public in NEAR data. Cross-chain claims are disabled; ordinary supported-asset push payments remain available.

Checking your support sign-in...