Docs updates for E/A#100542 Add Rillet vendor matching help article

[MelvinBot]

Explanation of Change

Help site follow-up for #100542, which added Rillet as a vendor matching source (cascade order QBO → Sage Intacct → Xero → Rillet), wired Rillet-specific empty state copy into the vendor selector, and included Rillet in the Vendors row detection on the More features page.

The help site already documents vendor matching per integration — Manage Vendor Matching for QuickBooks Online and Manage Vendor Matching for Sage Intacct — but had nothing for Rillet. This PR adds the matching article:

docs/articles/new-expensify/connections/rillet/Manage-Vendor-Matching-for-Rillet.md

It covers who can use Rillet vendor matching, how vendors are matched automatically, selecting a vendor manually on an expense, where the imported vendor list lives, setting the Default company card vendor, the export order, and the Vendor no longer valid error.

Notes on the approach:

• Frontmatter uses noindex: true / sitemap: false, matching the Sage Intacct article, because Rillet vendor matching is still gated behind the vendorMatching beta (QBO is GA and its article is indexed).
• No cross-link was added from Configure-Rillet.md, again matching the Sage Intacct precedent for a beta-gated article.
• UI labels were taken from src/languages/en.ts on this commit and checked against the live web app: Accounting, More features, Vendors ("Match card expenses to vendors imported from your accounting software."), Default company card vendor, Find vendor, No vendors found, and Vendor no longer valid. Rillet is confirmed present in the Accounting connections list.
• No fallback vendor is documented for Rillet. QBO falls back to Credit Card Misc / Debit Card Misc and Sage Intacct to Credit Card Misc, but Rillet defines no equivalent auto-created vendor in CONST.NON_REIMBURSABLE_FALLBACK_VENDOR_NAME, so the article stops at the Default company card vendor.

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/678897
PROPOSAL:

Tests

// TODO: The human co-author must fill out the tests you ran before marking this PR as "ready for review"
// Please describe what tests you performed that validates your changed worked.

This PR only adds a markdown file under docs/articles, so there is no app behavior to test. Review should confirm the article matches the current behavior of Rillet vendor matching.

• Verify that no errors appear in the JS console

Offline tests

N/A — documentation only.

QA Steps

// TODO: These must be filled out, or the issue title must include "[No QA]."
// TODO: The human co-author must fill out the QA tests you ran before marking this PR as "ready for review".
// Please describe what QA needs to do to validate your changes and what areas do they need to test for regressions.

• Verify that no errors appear in the JS console

PR Author Checklist

• I linked the correct issue in the ### Fixed Issues section above
• I wrote clear testing steps that cover the changes made in this PR
  • I added steps for local testing in the Tests section
  • I added steps for the expected offline behavior in the Offline steps section
  • I added steps for Staging and/or Production testing in the QA steps section
  • I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
  • I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).
• I included screenshots or videos for tests on all platforms
• I ran the tests on all platforms & verified they passed on:
  • Android: Native
  • Android: mWeb Chrome
  • iOS: Native
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
• I followed proper code patterns (see Reviewing the code)
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I followed the guidelines as stated in the Review Guidelines
• I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG))
• If new assets were added or existing ones were modified, I verified that:
  • The assets are optimized and compressed (for SVG files, run npm run compress-svg)
  • The assets load correctly across all supported platforms.
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• I added unit tests for any new feature or bug fix in this PR to help automatically prevent regressions in this user flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

---

@ShridharGoel, please review the files changed and confirm they reflect the current behavior. Then post a new comment saying @MelvinBot mark this PR as ready for review.

[ShridharGoel]

@MelvinBot mark this PR as ready for review

[ShridharGoel]

Reviewer Checklist

• I have verified the author checklist is complete (all boxes are checked off).
• I verified the correct issue is linked in the ### Fixed Issues section above
• I verified testing steps are clear and they cover the changes made in this PR
  • I verified the steps for local testing are in the Tests section
  • I verified the steps for Staging and/or Production testing are in the QA steps section
  • I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
  • I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
• I checked that screenshots or videos are included for tests on all platforms
• I included screenshots or videos for tests on all platforms
• I verified that the composer does not automatically focus or open the keyboard on mobile unless explicitly intended. This includes checking that returning the app from the background does not unexpectedly open the keyboard.
• I verified tests pass on all platforms & I tested again on:
  • Android: HybridApp
  • Android: mWeb Chrome
  • iOS: HybridApp
  • iOS: mWeb Safari
  • MacOS: Chrome / Safari
• If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
• I verified proper code patterns were followed (see Reviewing the code)
  • I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
  • I verified that comments were added to code that is not self explanatory
  • I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
  • I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is either coming verbatim from figma or has been approved by marketing (in order to get marketing approval, ask the Bug Zero team member to add the Waiting for copy label to the issue)
• If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
• I verified that this PR follows the guidelines as stated in the Review Guidelines
• I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
• If a new component is created I verified that:
  • A similar component doesn't exist in the codebase
  • All props are defined accurately and each prop has a /** comment above it */
  • The file is named correctly
  • The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
  • The only data being stored in the state is data necessary for rendering and nothing else
  • For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
  • Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
  • All JSX used for rendering exists in the render method
  • The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions
• If any new file was added I verified that:
  • The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory
• If a new CSS style is added I verified that:
  • A similar style doesn't already exist
  • The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
• If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
• If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
• If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
• If the PR modifies a component or page that can be accessed by a direct deeplink, I verified that the code functions as expected when the deeplink is used - from a logged in and logged out account.
• If the PR modifies the UI (e.g. new buttons, new UI components, changing the padding/spacing/sizing, moving components, etc) or modifies the form input styles:
  • I verified that all the inputs inside a form are aligned with each other.
  • I added Design label and/or tagged @Expensify/design so the design team can review the changes.
• For any bug fix or new feature in this PR, I verified that sufficient unit tests are included to prevent regressions in this flow.
• If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
• I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: HybridApp

Android: mWeb Chrome

iOS: HybridApp

iOS: mWeb Safari

MacOS: Chrome / Safari

[melvin-bot]

Concierge reviewer checklist:

• I have verified the accuracy of the article
  • The article is within a hub that makes sense, and the navigation is correct
  • All processes, screenshots, and examples align with current product behavior.
  • All links within the doc have been verified for correct destination and functionality.
• I have verified the readability of the article
  • The article's language is clear, concise, and free of jargon.
  • The grammar, spelling, and punctuation are correct.
  • The article contains at least one image, or that an image is not necessary
• I have verified the formatting of the article
  • The article has consistent formatting (headings, bullet points, etc.) with other HelpDot articles and that aligns with the HelpDot formatting standards.
  • The article has proper text spacing and breaks for readability.
• I have verified the article has the appropriate tone and style
  • The article's tone is professional, friendly, and suitable for the target audience.
  • The article's tone, terminology, and voice are consistent throughout.
• I have verified the overall quality of the article
  • The article is not missing any information, nor does it contain redundant information.
  • The article fully addresses user needs.
• I have verified that all requested improvements have been addressed

For more detailed instructions on completing this checklist, see How do I review a HelpDot PR as a Concierge Team member?

cc @jliexpensify

[melvin-bot]

@jliexpensify Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

[MelvinBot]

Done — this PR is now Ready for review (no longer a draft).

Two things to flag before a reviewer picks it up:

1. The Tests and QA Steps sections still have the // TODO: placeholders. I left the body untouched since you only asked me to flip the draft status. This is a docs-only change (one new file, docs/articles/new-expensify/connections/rillet/Manage-Vendor-Matching-for-Rillet.md), so the QA section likely just needs [No QA] added to the title — your call.
2. I could not verify anything in a browser on this run — the web test environment failed to come up, so the UI-label claims in the PR description (Accounting, More features, Vendors, Default company card vendor, Find vendor, No vendors found, Vendor no longer valid) are carried over from the earlier run and were not re-checked live.

Checks are green apart from Check independent approval, which is expected on a MelvinBot-authored PR and clears once a human reviewer approves.

[github-actions]

Terminology consistency: Capitalize "Workspace" here ("If a Workspace merchant rule..."). Everywhere else in this article "Workspace" is capitalized as the Expensify feature name; per the naming conventions, UI/feature terminology must be exact and consistent.

[jliexpensify]

@stephanieelliott - I think Melvin is correct, this should be a capital right?

[jliexpensify]

LGTM

[github-actions]

HelpDot Documentation Review

Overall Assessment

This PR adds one new help article, docs/articles/new-expensify/connections/rillet/Manage-Vendor-Matching-for-Rillet.md, documenting Rillet vendor matching for company card expenses. It is a documentation-only change (101 additions) that follows the established precedent set by the QuickBooks Online and Sage Intacct vendor matching articles. The article is well-structured, tightly scoped to a single workflow, and closely adheres to the HelpDot governance standards.

Scores Summary

• Readability: 9/10 - Clear, concise prose with well-formatted sequential steps, scannable sections, and a benefit-focused intro. Cascade/ordering logic is explained plainly with a concrete example (STARBUCKS number 456 matches Starbucks).
• AI Readiness: 10/10 - Every heading is task-based (Who/How/Where), only single-hash and double-hash levels are used (the second single-hash is the exempt FAQ), the full feature name appears throughout, and complete YAML metadata is present including a detailed internalScope with explicit exclusions.
• Style Compliance: 9/10 - UI labels are bold and in correct sentence case (Vendor, Default company card vendor, Find vendor, No vendors found, Vendor no longer valid), the unified navigation sentence matches the convention exactly, and terminology (Workspace, Workspace Admin) is correct. FAQ structure is compliant.

Key Findings

• Single-workflow scope is respected; the article correctly stops at Default company card vendor and does not invent a fallback vendor that does not exist for Rillet.
• Metadata is exemplary: descriptive keywords, and an internalScope that names the audience, covers included workflows, and lists explicit exclusions.
• The single cross-link (to Connect-to-Rillet) uses a relative path, descriptive anchor text, and sits in an explanatory sentence rather than a numbered step, fully compliant with cross-linking standards.
• The screenshot suggestion uses the correct non-rendered HTML comment format with a specific, confusion-resolving Purpose.
• noindex true and sitemap false are appropriate given the feature is beta-gated, matching the Sage Intacct precedent.

Recommendations

• Minor: navigation steps use the placeholder [workspace name] (lowercase) while the template shows Workspace Name. Consider aligning casing for consistency. Non-blocking.
• No structural or compliance changes required.

Files Reviewed

• docs/articles/new-expensify/connections/rillet/Manage-Vendor-Matching-for-Rillet.md - New article. Compliant with governance; ready to merge from a documentation-quality standpoint.

Note: Detailed line-by-line feedback has been provided as inline comments.

[MelvinBot]

⏱️ Ran out of time before I could finish. This usually means the task was too complex or I got stuck exploring. Please try again with a more specific request or post in #melvinbot-ai.

Run details

[MelvinBot]

No code fix is needed — the build failure is an infrastructure flake, not a problem with this PR.

What failed: The Deploy ExpensifyHelp workflow died at the Install pcregrep step, before it ever touched the docs:

Err:2 http://us.archive.ubuntu.com/ubuntu noble/universe amd64 libpcre3 amd64 2:8.39-15build1
  Connection failed [IP: 91.189.91.83 80]
E: Failed to fetch .../pcregrep_8.39-15build1_amd64.deb  Connection failed
E: Unable to fetch some archives...
Process completed with exit code 100

That's the Ubuntu package mirror refusing connections at .github/workflows/deployExpensifyHelp.yml:41. The job never reached the Jekyll build or any doc validation.

Why it's unrelated: This PR changes exactly one file, docs/articles/new-expensify/connections/rillet/Manage-Vendor-Matching-for-Rillet.md. Every other recent Deploy ExpensifyHelp run passed — the 14 runs before this one on other branches and on main all succeeded. A re-run should go green.

I couldn't re-run it myself: my token doesn't have actions: write on this repo, so both gh run rerun and the rerun-failed-jobs API returned 403 Resource not accessible by personal access token. Please hit Re-run failed jobs on the run.

The other red check, Check independent approval, just needs a human reviewer's approval — nothing to push for that one.

Check status detail

Check	Result
build (Deploy ExpensifyHelp)	❌ apt mirror connection failure at Install pcregrep
Check independent approval	❌ awaiting human approval
spellcheck	✅
verify (Validate Docs Routes File)	✅
check (validateCode terminology)	✅
verifySignedCommits	✅
CLA	✅

Note: I diagnosed this from the CI logs and the workflow definition only — browser verification wasn't available in this run, and isn't needed for a docs-only change.